The first problem I see is that the estimation process is going a bit wide. Yes, developers should have a say in how much work they should be expected to take on. No, that does not mean that adding a single button to a web form is now a two-developer-week story (however many points that equates to in your business's estimation process). If that's the current state of affairs, then you as the project manager should be doing some second-guessing.
Second, I hear "from start (design) to finish (implementation and unit testing)" and the first thought that comes to mind is "you're doing it wrong". Your unit tests are a part of your design work as a developer/development team, and should happen first; you take the basic requirements, distill them into a simple "checklist" of "If... When... Then..."-type sentences, and then convert those sentences into a series of basic tests that assert the program meets those assertions and therefore the requirements. That happens before you write a line of the production code that will meet the assertions of the tests. If your unit tests come last, after you've already implemented the software, you lose several key aspects of unit testing; in general, your developers can't "program to green", thus providing a minimalist definition of "done" that encourages lighter (yet maintainable) implementations that do what the client wants without wasting work doing more things that the client doesn't want yet (and may in the extreme be unwilling to pay T&M for, because it's not what he asked you to do).
As far as developers "owning" their features, there's a yes and no to it. First off, a pretty common shakeout from "self-organizing teams" is a tendency for developers to go off in pairs or threes and work on things they know best. Assuming you have a good all-around set of developer expertise such that the team can cover all of the work to be done in each iteration this way, you can simply let this happen; it's a good thing for velocity, as developers stay focused on and familiar with the areas of the codebase they've been working in from iteration to iteration.
However, one developer owning one feature for life is a dangerous mindset, because it lowers the "truck number" of your team (defined very frankly as "how many people could be hit by a truck before the team couldn't function, given the worst case scenario of specific people hit and resulting knowledge lost). If the one guy whom you have assigned the "File Import" feature of your software and has owned it for 2 years goes on vacation for three weeks, takes extended FMLA leave, changes jobs, or in the extreme, really does get hit by a truck and dies, now you don't have anyone else who knows that feature because that area of the codebase has been that one guy's exclusive purview for years. While someone else familiarizes themselves with this particular piece of the codebase, you are going to lose significant velocity, and you will also open yourself up to additional problems with defects, as the new guy who's just barely familiar with how the codebase works now may remain woefully ignorant of things he can and can't change within it.
Instead, you should look to cultivate a division of labor that keeps your truck number at least 2 or above, and in a larger team (a dozen or more) closer to 3 or 4. That way if one guy can't do the job, for any reason, there are several other people who can jump in. Sometimes, teams just naturally shake out this way, especially if you bring in a few XP techniques like pair or dojo-style programming (one guy writes in a new assertion based on requirements that the code doesn't meet; the next guy then codes to pass that test, then adds another requirement assertion that fails and passes it on). By definition in these situations, you have multiple eyes looking at the code, developing it, becoming familiar with it.
Overall, the idea of Agile is to promote "lightweight" development. Your team seems to be getting bogged down in minutiae of processes and documentation, when the primary focus, as per the Agile Manifesto, should be on the team members and their interactions, and of course on working, functional code. The processes inherent in Agile are a means to an end, and there isn't any one way to follow Agile; even the primary Agile frameworks like SCRUM are malleable based on your needs as a company, a team, and even from day to day (just make sure to keep the basic ideas of the values provided by these processes at heart when making such changes).
