Another nice upside of this approach is it helps re-enforce a culture of doing the right thing because we ship and don't just write code.
You have to know your people, and give them support that motivates them. But that takes (gasp!) good managers.
My gut is that it goes the other way around. People who desire to work on the Big Cool Sexy New are often less motivated by peers, and more by personal drive, as by definition most of their peers won't know what the hell BCSN even is. Unless the person in question is working in a 100% BCSN shop, in which case there's likely to be fewer maintenance tasks in the first place as the codebase will be fresher.
For some developers (including me), working on projects with significant business value is the definition of glamorous. Since there's significant business value, then you should be rewarding people for delivering that value (with bonuses and raises).
If the task does not have significant business value, it's probably not actually important. A lot of maintenance tasks actually fall in this bucket.
I want to work on what's most important for the business and our users. Having engineers pick whatever they find fun to work on sounds broken, but I'm also interested in if and how that can be made to work.
Companies tend to try everything except the obvious: more money.
It might not work for everyone or every team, but it sometimes works for me.
Also I find it better to deploy juniors to glamorous tasks wherever possible. They benefit from the glamour to become self sufficient non-juniors.