Can't estimate that... it's a bug

Technical debt (so called) is most likely at the root of it. For a new requirement, an estimate can generally be made about how to bolt on new functionality. The hooks for doing so will at least be understood, even though the code providing the hooks started to rot ages ago and is now a mystery.

Fixing a defect means going beyond the hooks to figure out why the system is behaving in unexpected ways, then how to make a fix that doesn’t break something else. That’s where code rot clouds the vision.

How might a team running only with Kanban try and break down items on their backlog into relatively similar sizes if the majority of items are bugs, and the response to such an attempt is the above?

They might not do that, on the grounds that breaking-down amounts to time wasted which could be spent doing. It's possible they may be right.

Instead, they might just handle each backlog item as a ticket and rely on averaging-out to give metrics regarding throughput, lead time etc. That is also an approach which can be used in Scrum, and it may make sense if the majority of items are indeed bugs.

Have you considered putting the user story exhibiting the technical debt back onto the PB instead. At least then the developer might be able to estimate. Even if they have redo the story.

Would it be a candidate for a spike... break from actual work within a sprint to learn about the source of the bug for estimation purpose using the task with the bug as the source? Would that work?

I know some circles frown on spikes but technical debt is even more frowned upon.

Someone with more experience might have a better answer. 

Spike investigations are technical activities typically unaligned to the Sprint Goal and creating the Done increment. They can be seen as a highly focused kind of refinement, by means of which estimates for future work can be made. Hence there is usually only an appetite on the part of a team to do them by exception. There might be one or two in a Sprint for example. If there are too many of them they can impinge on the technical development effort.

Unfortunately in this situation it sounds as if there are a lot of bugs, and perhaps too many for a team to reasonably spike.

Instead, they might just handle each backlog item as a ticket and rely on averaging-out to give metrics regarding throughput, lead time etc. That is also an approach which can be used in Scrum, and it may make sense if the majority of items are indeed bugs.

Ok, this is interesting.  So if there are X number of bugs scattered throughout the Product Backlog, a team might base the average effort of previous bugs they've tackled as a team to come up with an estimate.  This would replace trying to determine the cause of the bug first then providing an estimate for the fix.

If a Sprint Goal is "improve the performance of the <something> feature" this might include the estimated Tech Debt/Bug PBIs. The Dev Team can still have a feeling for how much they can do in one Sprint based on this average estimate.

Yes. The challenge is ensuring that all work, including defect fixes, is accounted for on the Product Backlog. Remember that non-defect items might be estimated in story points.

This could be achieved by estimating each defect simply in terms of the average relative time, effort, and complexity which is empirically observed Sprint by Sprint.