The purpose of the Sprint Retrospective is for the team to "plan ways to increase quality and effectiveness", and this is done by inspecting the last Sprint in the context of "individuals, interactions, processes, tools, and their Definition of Done". There are any number of tools, techniques, or pieces of information that can help the team carry out the Sprint Retrospective. The team is free to choose how to achieve the purpose, and the Scrum Master is there to guide the team on their continuous improvement journey.
Does the team believe that spending the time and effort to produce a graph or chart showing how many story points were completed by each developer would help them find opportunities to increase quality and effectiveness? If so, then it may be worth running an experiment for at least a couple of Sprints and seeing if it helps the Sprint Retrospective. If not, then it's not worth it.
However, I do see some potential areas of concern with the plan.
First, individuals working on things alone tends to be an anti-pattern. It doesn't promote the cross-functional, cohesive, self-managing team that is central to Scrum. If the team is currently working together on work items, there needs to be a plan to make sure that everyone's contributions is considered, not just a single person who may be "assigned" to the work item in some tool. If the team isn't working together collaboratively, you'd probably see some gains if they were. Focusing on building a collaborative team would be more useful than gathering individual performance metrics.
Second, once you start collecting data, it often becomes harder to keep it contained. If your organization does individual-based performance reviews, this kind of data may be useful to managers as part of that process. If you aren't collecting it, it could be easy to explain why you aren't and why it's not worth the time to collect. However, once you start collecting it, it becomes harder to not share it. This entrenches the organization into thinking about individuals and output rather than teams and outcomes.
Third, it sounds like your process doesn't currently estimate every piece of work. If this is working out for you, that's good. However, if you need to mitigate some of the problems around getting visibility into collaboration, it sounds like you'll have to increase the effort put into estimating work. More effort put into estimation means less effort for other things, including delivery.
Is it a good idea? I'd generally lean toward "no". However, like most things, there isn't a one-size-fits-all solution. Scrum not only allows for iteration on the product, but the processes used to build it. You can run experiments and see if they are beneficial to the team or organization. If they are, you can keep them. If they aren't, you can drop them. You can also reevaluate past decisions at any point in time.