If you ask a kid what he wants for Christmas he can generally rattle off a dozen or so things (often in direct relation to what's featured in the commercials du jour). If you let a kid write a letter to Santa listing the stuff, things on the list start to take on a life of their own. Now, instead of just wishing for the swag, the kid starts expect it...there's something about writing down his wish list that seems to breed a sense of entitlement. By Christmas morning, if that Red Ryder BB Gun isn't under the tree, the kid is outraged; it was on the wish list! Now he's mad at Santa; the big red guy done him wrong.
If you encourage your users to pie-in-the sky a wish list, they may be doing their version of a passel of spoilt kindergartners if all the whizbang extras aren't in the system by implementation. Make wish lists at your own risk; set expectations oh, so carefully.
So, how to keep "nice-to-haves" out of the "must-haves" playground? You can attack the problem by rating each requirement, with the disco-ball, fab-but-not-core stuff ranked low. But in my experience that's a bad idea for at least two reasons: first, if you let not-really-requirements into your requirements docs, it fosters the idea that *everything* is negotiable. And second, it's a waste of valuable elicitation time. So there's some finesse then in recording those wish list things and then getting the focus back on the core.