Conversation is Not Inherently Disruptive
I work with a team of developers who are talented but often distract each other with chit-chat.
You say they are "talented but distracted." What makes you think they are talented? Why do you think they are distracted? What is your metric for determining that the team or the process is operating at a sub-optimal level?
You haven't really made a case for any of those things, except insofar as we're supposed to agree ab initio that "chit-chat" (which has a rather pejorative connotation) is disruptive to the project. How have you determined that the team's communications style is preventing your project from succeeding?
Self-Managed Teams and the 100% Utilization Fallacy
Ideally the developers would have expectations that would require them to stay focused and manager (sic) their own work.
While I agree that an ideal team is self-managing, I have no knowledge of your hiring practices, corporate culture, or organizational incentives for teams to be self-managing. However, the fact that you appear to be in a role where you are tasked with managing a team that isn't self-managing argues that expecting such may not be reasonable without changes to your organization or process.
In addition, "staying focused" is often management-speak for "looking busy." As above, unless you can make the case that your team is failing to perform, it really does sound like how they behave is more important than what results they produce.
In fact, by making "how" an issue, you're acting contrary to the very principle of self-management you seem to want. Even if the team is truly disengaged, your time would be better spent figuring out how to engage them rather than on ways to make them look engaged.
Developers are often odd ducks. Some developers work best in catacomb-like silence or working at 2:00am; others thrive on cross-talk and team engagement in the office. Regardless of work style, though, all developers need thinking time to be productive---more clicks on the keyboard (e.g. higher utilization) does not lead to more throughput or higher-quality code.
"Accountability" and Project Process
Even when I ask how long it might take to complete items (which I can complete in a very accurate time frame) I get negative feedback which indicates a desire to suppress accountability.
Again, your conclusion isn't based on information in evidence. There may be other reasons your development team doesn't want to give hard deadlines.
"Accountability" is a buzzword for a way to shift blame.
If your organizational culture likes to affix blame, and projects are often late or otherwise doomed to failure, why should the team want to be held accountable?
Commandments from on high aren't commitments.
If the team isn't part of the estimation or scheduling process, then they are being "held accountable" for delivery dates that they didn't sign up for. Ask yourself honestly whether developer estimates are solicited and honored as a project baseline, or whether project deadlines are set outside the team.
Estimates aren't commitments.
If a developer tells you something will probably take three days, but the job takes five, what happens in your organization? Is someone to blame? Does the developer get punished or denigrated for the mis-estimate? If so, why should they do anything other than slog onwards at whatever pace they feel is sustainable?
Commitments aren't guarantees.
Developers are rarely stupid. If they know something will take two weeks (due to complexity, process overhead, or organizational obstacles) and you think it will take two days, what's their incentive for giving you a different deadline? If the organization routinely cuts their estimates, and then holds them accountable, where is their incentive? If they give honest estimates, and fail to meet voluntary commitments through external impediments, does the organization expect a money-back guarantee in the form of unpaid overtime instead of trying to resolve the impediment?
Even if we assume that your conclusion that the team wants to avoid accountability is true, you haven't dug deeply enough into why. There's clearly an organizational or process issue at work here, and solving the perceived problem isn't really addressing the root cause---or buying you anything if you are ultimately being "held accountable" for a project that is failing.
Take an honest look at your organization, your project management process, and the members of your team. Try to be objective, and see if the incentives actually align with the interests of the developers. If not, start there!
Holding a Scrum-like retrospective might help, too. If the real problem you want to solve is getting honest estimates from the development team, the only people who can tell you how to get them are the members of the team. Of course, you will need to earn their trust (if honest communication hasn't been the norm), and there are no silver bullets. Still, it's one of the best tools out there: ask the people with the actual answers!
There are always other things you can inspect-and-adapt. Still, you need to start somewhere, and holding honest and open dialogs is almost always the very best place to do that.