I concur with some of the other points made, specifically:
- Not really a team and sounds more like multiple teams of one.
- Knowledge dissemination is also an issue.
- No real benchmark for the estimating.
I would add the focus of the question seems to be on finding a tool to overcome...something?? which makes me curious. What interactions are you trying to facilitate? What are the team and the business not getting?
Having said that, I hope you will allow me the following. One of my favorite lines from an Agile Coach I know is: Welcome to Scrum, where the stories are made up and the points don't matter.
It doesn't matter how many points you got done...at least not to an end-user or consumer of the product. One of the drawbacks to story points is that they can quickly turn into a way for the business to measure the team; this rarely ends well for the teams. Just a public service announcement.
Pair programming (or peer review) can help with the first two issues. Planning poker is a decent way to build consensus and discussion.
I might offer something else; so, to the question.
Find a baseline - each Sprint
You could do something like this.
At the beginning of each Sprint, have the team look at the prioritized backlog and pick the smallest thing that's somewhere at the top. Make that your one (1) for the Sprint.
Now, look at the thing at the top of the backlog. How many times more is it than the other? If the team says it's smaller, then you've chosen the incorrect one for the Sprint.
Then the question is, "Do you think you can get it done given all the rest?" If the answer is yes, bring it into the Sprint...then on to the next.
This is per Sprint relative sizing.
(Just in case it's not clear why.) The team is sizing things relative to a baseline selected each Sprint as opposed to comparing themselves or other things in the backlog to past information.
I appreciate this approach because it doesn't tie a point to a unit of time, which tends to happen when things like velocity and number of points completed are monitored. It can also stop the business from trying to project into the future of when something will be "done", which is its own blessing and curse.
But, the fact remains, the points don't ultimately matter...unless there's a clear, distinct, and embodied why; without it, it's a mechanical device the team (yourself included) thinks will help with...something??
What is the benefit to the universe that the team hopes using points will accomplish? When they commit to a Sprint, do they get the work done? If so, what does an estimate do (they accomplish their mission)? If not, how will an estimate help overcome overcommitting (the problem of not estimating well still exists)?
If the individuals aren't dependent on each other, for the most part, what does it matter if Sally estimates something as 50 points and Saim says its 10? Who's actually getting the work assigned to them? Is Saim dependent on Sally to get it done? If not, why does it matter if it's 50? Even if Saim is dependent, the points aren't the risk...Sally not getting done is the risk (at which point Saim could offer to help; Lean practice).
And a host of other questions. And, to fair, I'm not sure you've explored all this with the team yet, but it's not clear by the phrasing of the question.
When it comes to Agile Software Development, I always start with the values from the Manifesto. And, whenever someone comes to me with a question about something that falls in the "right" - I try to shift my focus to the left. In this case, the Agile Software Development value under consideration is:
individuals and interactions over processes and tools
Estimating, Planning Poker, and a host of others are, essentially, processes. Story Points, time estimates, and so on are tools. Which brings us to the left.
What interactions are you and the team trying to facilitate? How safe does the team feel with each other? What are alternatives to story points as a means of cultivating the new type of interaction? And, what's the maturity of the team when it comes to Agile Software Development (who are the individuals on the crew and where are they in their journey)?