I wouldn't normally rez such an old thread, but I don't think this has come up anywhere else (or been answered!), it came up on another site I'm on just now and the answer may be interesting

Short version: The quality value is still written by LAME if you encode a CBR file, and it does still carry some limited meaning (although the routines are in VbrTag.c, elsewhere in the source it talks about the boolean bWriteVbrTag which controls whether or not that happens: "It is used for CBR,ABR and VBR.")
in VbrTag.c:
int nQuality = (100 - 10 * gfp->VBR_q - gfp->quality);
So a V0 q2 will give 98, a V2 q4 will give 76, etc

So why do we get weird values for 320 CBR?
Well in lame_init_old (despite the name it is being called!) default values for the gfp struct are set, and one of them is:
gfp->VBR_q = 4;
I assume that this never gets overwritten in the case of a CBR file, the calculation for quality is done the same, and the header written. So, for a CBR file:
quality value = 60 - q
Programs that give you the VBR no. and q value from an MP3 file (including LameTag I guess, we were talking about AudioIdentifier) work it out backwards from the quality value. If you get 55 then that MP3 really was encoded with -q 5, just ignore the VBR value and you do have some meaningful information

Hope that's helpful / interesting to someone!