A Scrum Alliance article has this to say about tech debt and how to manage it in the Scrum workflow
Servicing the technical debt
The first step in servicing the debt is to identify any such issues and register them — making the debt visible for the team. These could be made part of the product backlog or even be part of a separate technical debt backlog for purposes of tracking. The team can then evaluate and prioritize, taking into account the effort required and the “pain” caused by the technical debt and its frequency. The product owner would need to make a conscious decision whether the “economics” justifies the cost of the technical debt. It has to be kept in mind that not all technical debt need be repaid; e.g., one can live with issues relating to a product nearing its end of its life. However, it is important during this time that technical debt is not accumulated, since that would only cripple the system
From David Hawks, CEO of Agile Velocity, who sums it up like this
In the sprint I believe all work should be made visible. I probably wouldn’t put points on it since it isn’t part of the release plan. Also I encourage folks to track a separate tech debt backlog to make that backlog of work visible and prioritized
In other words, the Product Backlog should still only be populated with user stories, and user stories should always be testable and estimable, but you also want a Tech Debt Backlog populated with tech debt stories that aren’t necessarily testable or estimable. This separate Tech Debt Backlog makes it clear to the testers that this isn’t something they need to test, and it’s a useful way of capturing work that might normally be a spike time box or just skunkworked outside the workflow.