I must admit that I don't know whether OS X has information like a received strength indicator easily accessible.
What I can tell you from an RF communication's engineer's perspective is that the displayed signal strength is everything but accurate, and it's even less usable to really predict how well communication will work.
As you said, the bars aren't enough information for anyone -- and the fact that there are already five different amounts of bars you can have usually greatly exaggerates the accuracy with which these things are available to the operating system. WiFi quality is so much more than received signal strength that you can't directly map bars to quality. I really don't know why GUIs keep including that measure instead of e.g. a measure of how many packets get lost along the way (which is actually something that an OS can observer).
I assume you want to do something like "if WiFi A is weak, switch to WiFi B", or similar. I think the right way to do that is actually two steps up the OSI layer model, at least. I'd personally just set up a server somewhere on the internet that replies to UDP packets and is pingable. Then, you'd just use standard ping to figure out whether latency is still acceptable, and use short UDP to the server packets to figure out how much packet loss you see (you can do that via ping
and ICMP, too, but that won't normally allow you to send a couple of hundred packets per second -- which is what I'd do periodically).