I'm making this a separate answer because while it has some of Bevan's answer at its core, I'm expanding on it a bit. I, too, have never seen a formalized way of doing this.
Mine is an Agile shop building a SaaS app, with a team of 4 developers and a tester, working on 2-weeks sprints. When the team decomposes stories, we create a parent ticket and children tickets that roughly work out to be model changes, view changes, and controller changes (broadly speaking) to achieve the goals of that story.
When it comes time to work, one developer grabs the parent ticket, and for the life of that work within the sprint, they become the "owner" of the code that goes into realizing that story. However, it is quite common that other people on the team work on the child stories depending on personal strengths (e.g. UI, database, an extra dose of business logic knowledge). The "owner" of the parent ticket is the go-to for questions about that feature or component (whatever the case may be) until all the children are completed and the owner works through the whole item at the parent level and is ready to send it as a bundle to the code review status.
When items go through code review, they do so at the individual child level as well, and the only rule is that no one reviews their own code (obviously). So, while Developer A might be the owner of the parent ticket, he could have worked on Piece 1, 2, 3 while Developer B worked on Piece 4, 5, and Developer C on piece 6, 7. Developer A would be able to code review 4, 5, 6, 7, Developer B could code review 1, 2, 3, 6, 7, Developer C could code review 1, 2, 3, 4, 5. When the code makes it through Code Review, it goes to test.
The tester tests each child independently if it has its own acceptance criteria, and the parent as a whole (which definitely has its own acceptance criteria). Here's where "ownership" comes into play again -- the owner of the parent is responsible for any fixes in the parent or its children. "Responsible" in this case may mean "having a conversation with whomever worked on a problematic child" but it is the parent owner's to get right.
The thought with all of this, and it's worked ridiculously and shockingly well with my team, is that everyone is always both an owner and a helper, everyone practices collaboration and communication constantly, and everyone is then familiar enough with every piece of the system that after the release anyone can be an owner of anything for the short period of time that owners have a role (e.g. within a sprint).