Whether you give them the name 'stabilization' or just 'Sprint 12' doesn't matter, at some point your team will have stopped initial development of stories and will be doing sprints of technical debt or closing off stories that haven't been done because issues were found and you couldn't close them. These are just normal agile sprints, my guess is your team is like ours and knows we'll need that calendar time to deal with the "I didn't think of that" stuff.
In our shop, if we initially forecast a release backlog of 400 points, and initially think we can do 100 points velocity based on history, that should theoretically mean we can do that in 4 sprints. However, we also have enough experience on projects to know that our estimates of velocity and total backlog are not always correct. New functionality might be required for the MVP, an unforeseen delay might block us from completing something, so we plan a similar 'sprint' for dealing with that. So we might put 5 or 6 sprints into our calendar plan to account for the level of unknown.
Now, the amount of time you are forecasting for 'stabilization' indicates an organizational issue with delivery if you need almost as much time to stabilize as to initially build. As others have mentioned, you likely need to embed your testing earlier on in the phase so that you are getting your feedback earlier. By using Continuous Testing techniques you will have your team cleaning up the stories as you go. That way, when your team is actually 'done', the release is ready.
ASSUMING YOU MAKE THIS ADJUSTMENT: Now we get to the release management part of our question: how do you deal with trying to finish off the release while also starting a new release in parallel? Typically, the last sprint or two might not have enough work in it for your initial release to keep the whole team busy. This is when you can start bringing in your next release stories to keep the team at capacity. From a code management perspective, using your favourite branching strategy will help to keep the codebases isolated and your team can switch between branches based on the task they are working on. From a task management perspective, you need to be able to clearly delineate to the team which release a feature is for so they know where to put it.
Should you split the team? Personally, I have found this helpful to keep team members focused, but it really only works if your team can truly work on almost anything. If you have specialists at all, they will have abilities that everybody needs and they will need the flexibility to jump between releases. If you can define a core group to deal with both releases and then other team members which can float this can allow for a more balanced attack.
WHAT IF YOU ARE NOT CONTINUOUS TESTING? If you are building a bunch of code, throwing it over to another team, and then moving on to the new release and waiting for feedback, you'll need to manage your team differently. This is a more 'waterfall' manner of delivery and means the initial release team can't predict when feedback will come, or how much there will be. This makes sprint planning harder for the next release since you can't be sure how much work from the initial release will be there. In this scenario, you may need to plan your new release sprints to have a 'buffer' in the capacity to account for feedback from the test team. You'll likely use your whole team for the new release at first, and once you have some technical debt to resolve you can start forming a group to deal with that and clear it out.
