That will just lead to stories to change something simple the color of a button taking 3 days because you hit a tech debt minefield refactoring. You don’t want someone looking at JIRA and seeing it took you 3 days to change a simple button color.
Keep technical debt in separate tasks to make the tech debt visible and to keep management accountable for not making efforts to get rid of it.
That will risk making a huge technical debt section in the backlog that will find it hard to get priority. It's better to condition new features/bugfixes on the cleanup that caused them. "I can add this feature in 1 day but will need 4 days to clean it up. So my estimate is a week." I constantly nag developers to do this when they find that they are pressed for time and want to make a hack.
-"I'm nearly done but I can't find a nice way of doing this because of an existing code smell so I'm considering adding another smell"
-"Did you ever find that this was NOT the case?"
-"No..."
-"So do you always double or triple your estimates so you know you can comfortably refactor"
-"No..."
I think this is a disease of Scrum. Too short estimates exist because developers pat themselves on the back for finishing things quickly.