Goto to nvidia.com, click developer, and browse their whitepapers. Usually the latest papers directly talk about the latest cards, so if you're worried about older cards you might want to check papers from a few years back. Repeat the process at ati's site.

If your VBs and textures don't fit into video memory, then yes, too large a VB may cause a performance hit, as the entire buffer must be swapped in and out of video memory at once. Personally, I keep a list of formats, and a list of VBs/IBs/shaders (in DX8 a shader is tied to a format) for each format. If I load an object, and it fits in one of the existing VBs, I put it there. If not, I allocate a new VB, but I have a minimum size, programmable per app at initialization... I think we tend to use 5,000-6,000 verts. If you load lots of small objects, they'll share VBs. If you load a detailed 10,000 vertex mesh, it gets it own VB.

If you know your level requirements, you can better tune how you allocate space, but that's only going to be set in stone at the end of your project (or a data pre-processing step). Until then, try to share the VB with small objects. Another problem with creating a very large VB is waste. If I changed from buffers of 6000 vertices to buffers of 20,000 vertices, using a typical 32 byte vertex, my possible wasted space goes from 192,000 to 640,000. If I still target an 8MB or 16MB card, that's a bit percentage of possibly wasted space. Cards that old will also likely be AGP1X or 2X, or even PCI. Combine slow bus with large buffers, and a sort that doesn't sort by VB, and you'll have a problem.

I think nVidia once suggested 1M-2M buffers are good, or ~31K vertices... but really, your optimal buffer size depends on your app's usage patterns and target hardware.