I've worked with product owners or customers that complain that marking an item on the backlog as low priority instantly sends it to the graveyard to live for eternity and never return. They know that the branding, design, and usability issues on the site are cheap to fix but are not important enough to prioritize in isolation.
When you have enough, group them together. Have a story that is "improve the experience of your sign-up process". Lump all those design, usability, and branding bugs into one story and make the team bang through them. (Of course, maybe they shouldn't have gotten through acceptance in the first place, but I needed an example and this reflects reality in a couple places I've worked.)
Another option: When the team picks work for a sprint, they pick up a few big stories and typically have a point or two of left over space. Make them pick up some cheap stuff off the bottom. Have them pick based on closeness to other stuff they are touching. Or have them pick based on value. After all, getting $10 of value for 30 seconds of work is slightly better than getting $1000 of value for over an hour of work.
This was the idea behind the first part of my comment about backlog prioritization on vikramadhiman's agile diary blog.