Sounds like it would do more harm than good. Ignoring for a moment whether it is fair for a manager to do that, let's look at the logistics...
Problem 1: Are all bugs created equal?
Developer 1 introduces a bug: Erases all customer data and curses at them.
Developer 2 introduces two bugs: Form labels are not left aligned, and the calendaring feature is off by 1 second if an event is created that spans two leap years.
So clearly developer 2 deserves more grief from their manager because they have double the bug rate. Of course not, so you come up with a bug rating system so developers with trivial bugs don't get dinged so hard. But wait, should the system factor in a modifier for a developer who is clearly making the same trivial mistake repeatedly and wasting the tester's time because they never learn from their mistakes? Maybe, hmmm. This is complicated.
Problem 2: What counts as a bug?
Manager - This report was supposed to include a running total, that's one bug for you!
Developer - That wasn't in the requirements, that's a FEATURE not a bug.
Problem 3: How do you group bugs?
Developer - "[Manager's Name], the testers filed 10 bugs against me because the velocities were incorrect on 10 different screens, but that was all related to a single bug in the getVelocity function. We argued for 3 hours about it, but they won't budge. We would like a sit down meeting with you to decide how many bugs should be filed. Oh and by the way, there is no way we are going to hit the code complete deadline tomorrow."
Problem 4: More SLOC probably means more bugs
Developer 1 sits on his butt all day, but manages to write 3 bug-free lines of code between arguments on Reddit over Arizona's immigration law.
Developer 2 works hard all day and churns out a fully functional AI that won't kill John Connor the first chance it gets."
So obviously you want to penalize the developer who makes more progress and/or takes more risks by innovating, right?
There are probably workable solutions to several of these, but as a manager of a programming team trying to meet a deadline do you really want to have everyone spending time arguing about what counts as a bug, what counts as a discrete bug, the importance of a bug, etc.? None of these things move your project forward and this will be poison for teams who will be forced to compete on issues that have no meaningful impact on the actual software being created. Not to mention what it does to your employee culture to focus this much effort on finding ways to make sure that every employee's mistakes are meticulously recorded so they can be thrown back in their face later.
Inevitably you will have developers cajoling testers to work around your bug tracking system and report issues directly so they can fix them without it going in their "PERMANENT FILE". Then you don't even have an accurate accounting of bugs or what people are really working on.
Then there is the issue of adverse impact. That is HR talk for, you better have pretty good documentation before you start penalizing employees, especially financially. And if any of them are a protected class (minorities, veterans, women, handicapped, etc.) you better be triple sure that whatever system you have set up doesn't discriminate against one of them based on membership in that class (or that a judge could be convinced as such), even if it is just an unintended side-effect of the plan.
So ultimately, you are not creating incentives to create less bugs, which is hard, but rather to negotiate away bugs by minimizing their importance or blaming them on someone else.
Short Version No.