On the bi-weekly sprint planning - yes.
From what's actually on the backlog - definitely not.
Opportunity Team meetings (or stakeholder chats - lead devs, architects, support peeps etc) always cover the general direction we want to go and are where the ideas for the backlog come from.
Example of easy benefit is if we have two things we want the product to do - this is where you learn what the options are and more importantly the rough costs/impacts.
If something's going to cost 10x as much and require refactoring, I suddenly decide I don't want it as much as the other option.
Can also come up from mid-sprint from dev.
(Real example) I had a US to add a new button. Dev noticed there was an internal 'button framework' already in place (as somebody had some a good job in the distant past). She asked if I could add a new US for next sprint to continue this work, so she could extend this framework and allow us to publish it.
i.e. Focus on adding new controls to the config tool, and then delivering on the original US with a bit of config.
I had no idea this untapped potential even existed - but for 2 weeks effort of one person, my product now has a configurable UI.
Lost count of the number of issues where a customer query can now be answered with - Just add a new button/tab/menu (and then over time it's been easy to add contextual controls, make more tokens available to the target builder etc etc)
"Technical Debt" is often mentioned (hidden cost of a hacked together mess, increasing the cost of the next feature to be piled on top). What's satisfying are the "Technical Assets" like this - not just for me as I get a better product, but for the dev who can take pride in building something elegant and knowing this feature is theirs.
