Short answer: There is no reliable way to get this information.
Long answer:
There are numerous, deprecated ways to get this information. Like opening an old DirectDraw interface and query the available video memory. That number however may include AGP memory, unified memory or it may not include it. Or you may even get a dummy value hard-coded into the driver.
I know you already know that querying this number is a bad idea, but let me summarize it again for the other readers:
What do you want to do with the number at the first place? As an application programmer you have very limited control how the video-memory is used. You don t allocate or manage memory in any way. The driver is doing this for you. Making your code aware of the "faked" available memory will lead to serious problems.
You may think you can use the available memory to decide how many textures will fit into the video memory, but that s a false assumption. Some cards have very strange requirements how the memory is used. One particular card that I know some details off has a minimal size for any mipmap of 4kb.
So if you would load a 8x8 8-bit texture into memory you may expect it to take 85 bytes (8*8+4+4+2+2+1). After the driver did the upload job it ll be 12kb in size however (4 * 4kb). Your estimate would be off by more than a factor of hundred.
The same applies to vertex and index-buffers, render-targets, shaders and so on.
That s the reason why this information does not get exposed to applications anymore. It made to many problems in the past.
