I think this mechanism would have real value only in a specific set of circumstances.
In the general case, of a regular web application, you'd be better just fixing your code to be XSS-safe, as @SteveS wrote.
However, there are some scenarios where that is not easily possible, and these scenarios are growing in popularity. I'm referring to "user-generated content", where you need to allow users to enter (almost) any data at all, including arbitrary HTML content - blogs, social networking sites, CMS, etc...
Now, the security-pro part of me is cringing from that, and right away I wanna jump and shout: "No, you don't need to do that, find a better way!". But of course that's not really the point...
And yes, there are roundabout ways to avoid that situation, with having users enter arbitrary HTML - either whitelisting certain tags, or using an alternate markup system (like Markdown used here) - but those are kind of a kludge, limiting in functionality, and not trivial for some end users.
Bottom line, there will be some webapps that will accept arbitrary HTML, for whatever reason the business deems necessary, and it can be counter-productive to shout about how insecure it is, cuz that just aint gonna work.
In these cases, Content Security Policy can add great value, and mitigate the XSS feature to a great extent.