No Invisible Work, Ever!
Work is work, whether it's on bugs or new features. Therefore, all work needs to be tracked on the Sprint and Product backlogs, regardless of the source. If you are using Kanban, it is certainly possible to have a separate queue for bugs vs. new work, but unless you have separate development and maintenance teams, it doesn't matter: you still have queue and global work-in-progress limits that need to be honored.
Bugs Should Slow Velocity of New Features
Bugs, refactoring, and other types of rework are a form of technical debt. Since they count as work, they should actually have no impact on overall velocity if the work is being properly tracked.
The only time hot-fixes and production patches will appear to slow a team's velocity is if the technical debt is not being accounted for. If you were an accountant, this would be called "cooking the books" and would be illegal--so don't do that.
Of course, iterations are time-boxed, so time allocated to fixing bugs or paying off technical debt means less time for new features. This is correct, and an intrinsic part of the framework: to identify the capacity limits of the system, and present the organization with the opportunity to inspect-and-adapt its processes.
Velocity Isn't a Delivery-Date Commitment
Of course, even if your per-Sprint velocity does have wild swings, your average velocity should remain fairly stable. If it doesn't, then the process should be reviewed to uncover the source of the problem: it could be poor estimates, invisible work, technical debt, process issues, or something else. Find out!
More importantly, if average velocity is being impacted by interruptions to the Sprint by support work or technical debt, that's great! That means the velocity metric is doing its job of making the impact to the system of this rework visible to the organization. That's all velocity is really for: measuring variance in team output, and identifying process issues.
Don't Abuse Velocity
If you're using velocity as a management target of how many features must be delivered each Sprint, rather than an estimation and feedback tool, then it's being misused. Velocity is for estimation, and provides a secondary function as a detective control to identify process bottlenecks.
Options for Managing Support/Maintenance
You have some basic options here.
Treat bugs and support work as normal Product Backlog items, and require the Product Owner to prioritize them along with new features. In this case, hot-fixes may not interrupt a Sprint without an explicit abnormal termination by the Product Owner and a return to Sprint Planning.
Have one team for support/maintenance, and a separate team for development. I would recommend adopting Kanban or some other pull-system instead of Scrum for the support organization, since it's often a better fit for ticket-based demand-queuing, but that's up to you.
Reduce work-in-progress limits (for Kanban) or story points per Sprint (for Scrum) to provide sufficient slack in your process--including task-switching overhead--to handle demand-driven interruptions like hot-fixes. If 30% of your capacity is being spent on untracked technical debt, then you need to reduce your velocity estimates by 35-50% to account for it. It's better to track the effort directly, but fudge-factors can work, too.
Educate the Organization
Ultimately, the goal of project management is not to sweep work under the rug, but to make the cost of work (in time and money) visible to the organization so that accurate estimates can be made. Providing honest metrics and accurate estimates to the organization allows business leaders to make informed business decisions--and the more information they have to feed the decision-making process, the better those decisions can be.
Make sure that management understands that velocity is primarily an estimation tool, and occasionally useful as a detective control. Velocity is not a substitute for capacity planning or process engineering. Part of your job as a project manager is to explain the value and proper use of your metrics to the organization.
Be an honest information broker. Making sound business decisions that ensure the success of a project is senior management's job, and your responsibility is to make sure that they are as fully-informed as possible.