How do you handle a pool of unrelated small bugs in Scrum?

We've recently adopted Scrum on the job and are running into trouble with a bunch of tiny bugs that appear after code has been accepted. These include things such as spelling errors, and other single line fixes. To create stories of size 0.5 for every little thing seems like a waste of time. It takes more time to write the story and point it than it does to make the fix. If there were only one or two of these per sprint, it would be easy to just fix them and not worry about creating stories for them. However, if there are 10 or 20 or more because the application is large, this can start to add up to significant amounts of developer time that aren't being accounted for via Scrum. While it may be easy to say the QA staff and product owners should be more thorough before the original story is accepted in the first place, I'm the developer so that is essentially out of my hands.

A couple imperfect ideas we've come up with so far:

Have a story that says "90% of bugs fixed in the app" where you then guess how many bugs will emerge in that sprint and how many can be fixed and then point it based on the anticipated workload
Have a story of size, say, 8 that is ALWAYS accepted at the end of the sprint where you fix as many bugs as you can. This obviously requires a great deal of trust that everybody is actually doing an 8's worth of work
Record bugs but do not work on them until the next sprint. They can be pointed individually or as a group. This has the advantage of being more "Scrummy" but causes a three week delay for what are essentially 1 hour fixes.

Any suggestions?

Solution

Your third answer is the best method. A sprint is simply a commitment by the team to complete a specified amount of work in a defined period of time. If you're accepting additional work in the middle of the sprint, you're deviating from that original commitment by working on things that were not committed to by the team at the beginning of the sprint.

Here's what we do:

All stories within a sprint must be defect free in order to be considered "done"
Any defects that are found during a sprint for a previously completed story are logged and put into the backlog. They're estimated just like anything else and prioritized by the product owner. If a product owner prioritizes new features over defects, they're choosing functionality over quality and vice-versa.
We don't assign story points to defects, but we do estimate every defect as it gets accepted into a sprint as part of planning. The team shouldn't get credit for broken functionality, but by the same token the time it takes to fix them needs to be recognized -- this accomplishes both.

Here's the problem with your other solutions:

Have a story that says "90% of bugs fixed in the app" where you then guess how many bugs will emerge in that sprint and how many can be fixed and then point it based on the anticipated workload

Again, see above. You want to avoid empty buckets of work that can be filled during the sprint. This defeats the purpose of a defined commitment by the team. How can the team commit to something they don't know about or haven't estimated?

Plus, this can easily spiral out of control into a product owner that will "design by defect" by filling that bucket with nice-to-have functionality that is really masquerading as defects.

Have a story of size, say, 8 that is ALWAYS accepted at the end of the sprint where you fix as many bugs as you can. This obviously requires a great deal of trust that everybody is actually doing an 8's worth of work

This sounds strange. The team should be accepting work at the beginning of the new sprint planning, not at the end of the previous sprint. Additionally, this will really skew your velocity over the long term. Scrum refers to Product Backlog Items, not just Stories, so there's nothing to say that you can't include defects as PBI's.

Record bugs but do not work on them until the next sprint. They can be pointed individually or as a group. This has the advantage of being more "Scrummy" but causes a three week delay for what are essentially 1 hour fixes.

You make an interesting point and we had some concern about this as well. However, that 1 hour fix (regardless of how quick it is) may not be time well spent when stacked up against the other things in the backlog. The bottom line is you want to push these decisions off to the product owner and give them the freedom to prioritize EVERYTHING the team spends effort on.