Collective code ownership is not an integral part of Scrum.
It is, however, a part of Extreme Programming. Extreme programming & Scrum work very well together.
The central element in Scrum is the team. Therefore, it's highly encouraged to practice collective code ownership in opposition of any sort of individualism.
Scrum works best in big projects (>$1M) with a lot of uncertainties and with big teams (>=5 devs on same code base). Weak code ownership can be very effective in smaller teams and smaller projects as Paul Graham describes it.
On the topic of code ownership, I think this post here puts it better than I could ever possibly write:
I don’t want to depend on anything without an owner. I see how this reasoning can be infuriating. Shifting the focus from software to wetware is a dirty trick loved by technically impotent pseudo-business-oriented middle-management loser types. Here’s my attempt at distinguishing myself from their ilk: not only do I want to depend on stuff with an owner, but I require a happy owner at that. Contrary to a common managerial assumption (one of those which rarely hold but do keep managers sane), I don’t believe in forcibly assigning ownership. If the owner doesn’t like the module, expect some pretty lousy gardening job.
/fanatical weak code ownership believer.
I don't think collective code ownership is absolutely necessary for scrum, however, the less code ownership, the more flexibility there is in task assignments. This is especially true when there are multiple scrum teams. Less code ownership also removes the bottlenecks that can develop when one code owner is overworked.
Code ownership does give continuity to development and depending on the skill sets of team members, it may be impossible to remove completely.