I've never used metrics in this way, however, you can build a case with some care and a lot of data mining.
First find out the average time cost per bug found by customers. You're going to need to find out how much time is spent in diagnosis, fixing, devising workarounds, and pushing patches, and average over the total number of bugs (this will never be anything but a crude measurement because no two bugs are equal, but if your management wants numbers, it's a way to give them numbers).
Next, look at the average time cost per bug found by the test team. This is also going to be a very crude approximation, but can be done via the amount of time spent per bug.
Rinse and repeat the time cost per bug calculations for each step of the process as best you can. What you should find is that on average each bug caught before release saves the company some number of hours developer time. If your company charges a per-hour fee for custom work, use that number to calculate savings, because time spent working on bug fixes is time not spent working on customer requests or new features.
As long as you emphasize that it's an average and the actual differential is going to vary (also, that a good test team is going to catch all the critical bugs prior to release, so the company shouldn't have to face the cost of a humiliating public failure), you have a starting point for discussion.
Never use these metrics to evaluate the team performance. I can't stress this enough. These are averages and act as proxies for customer goodwill retained by relatively bug-free releases. They don't say anything about the performance of the team as a whole or individual team members.