You should not have stabilization sprints. Your software should be releasable every sprint. This means that if you need stabilization, that has to happen within each sprint and not just before a release. Once you achieve this, release planning becomes a product owner concern ("What features to I need in order to release?") and stabilisation a team concern (definition of done).
The same applies to bugs and technical debt: it's stuff that is always fixed, as needed and does not require stories -- in fact, it's normally part of each story: it can't be "done" unless it's stable and properly refactored.
I realize that this does not answer your question directly, but stabilization is not an agile concept at all, so it makes no sense to ask how to do it with Scrum.
Edited to address comment:
According to Scrum, bugs found pre-release are to be handled within the iteration. A story is not normally considered "done" if it has bugs. If you can't ship it, it does not have value. Also, according to basic Agile principles, teams should work at a sustainable pace. If you need to basically stop development in order to address debt or bugs, then you are not working at a sustainable pace. Decrease your velocity, ship less features, but without bugs.
Usually stabilization happens in teams that have a separate QA team checking features post hoc. This does not fit in the Agile or Scrum model. Teams should be cross-functional and able to ship a feature independently.
Overall the thing is, many companies say they do Scrum or Agile without understanding the deep changes it entails in the way software is built. If you are not prepared to build software according to these methodologies, don't use it as a "management add on" on different practices.
Best Answer
Communications.
Large part of working as agile team is knowing what your team is working on. You have planning meetings and you should have design discussions prior to going off and coding solo.
On our teams we always know what other developers are working on and as soon as the thought arises that there's a potential for reuse or for overstepping bounds, you get up and walk over to the other person's desk (or if remote, pick up the phone).
UPDATE (response to comment):
At the beginning of every sprint, the team decides which stories are to deliver and which tasks are to be completed. We have a standard template (kinda like a checklist to make sure nothing is forgotten) and one of the things, is design task.
Almost every story has a design task, but generally it is 10 min to 1 hour discussion among team members to discuss the general approach of completing the work ahead. This not only serves as a heads-up for other people, but it is also useful because sometimes other people will offer a different solution that is better than what you were considering doing. In planning meeting, we decide which developers should participate in the discussion based on a) complexity and b) other people's familiarity of existing code that's involved.
If two people know they will be working in similar area, they will most likely participate in the same discussion. Our agile teams also have a technical lead, who typically participates in larger portion of design/code reviews and one of the responsibilities of that person is to spread knowledge through out the team, but I have a feeling this is a temporary position we will get rid off (or maybe scale back) once other team members get more familiar with the product (currently lots of fresh members).
Also during daily stand ups we generally talk about what we've been working on and what's ahead and if I mention that i started writing a utility class to help with feature X, and that class is useful to another developer, then the other developer would talk to me after the meeting and we would discuss how to make sure we are not repeating work and the class is generic enough to satisfy everyone's needs.
Finally, all code written is code reviewed, and we rotate through who reviews what, so in general the team has good familiarity with the whole code base. Even if two duplicate classes slip through (and I can't think of that ever actually happening), 95% chance this would be brought up in a code review and the two classes would be merged into one at that point.