Perhaps, I would suggest a different design and approach though to simply filling the screen until it's full.
I mean something I've noticed that is quite bizare is some processor models (not the Core 2 Duo/Quad) will expand how many models are possible on-screen due to their capabilities handling objects for DBP. Rather than the polygon count actually available.. there is also a very bizzare issues I've noticed where your app dramatically drops FPS when the models have their backs to you.
I'm sure more people would like to know what the card can push, but also how it would react in a real-game environment. So I'd suggest sitting down and looking at other benchmark products, how they do scores.. then think of imaginative ways of pushing the polygons possible with a card without this "increase models" method.
For example, while you could do the increase; the DirectX test to show performance difference between alternative rendering and sorting orders. That has a 10,000 polygons un-textured model; that you can have at increments of 1, 4, 8, 16, 32, 64.
You can run the test for each of those and rather adding, just run those rotating for about 30seconds. Adding up the Polygons Per Second, then divide by 30 for the time.
This would give an accurate untextured with 1-light source. Polygon count.. then add a 512x512 texture for them, then 1024x1024, 2048x2048 then 4096x4096. This could then provide the best texture option for ppl based on which performs the best on their card (given each model would take up the size of the texture for each model.. so wouldn't slow over un-textured until it peaks at a resolution.
Then run again at 1024x1024 (usually best possible texture, although most games will use less realistically) with multiple light sources.
Then again with shaders.
I mean each one would benchmark what is possible on that particular card and by running it for a specific adverage would make it relatively accurate to how many Polygons Per Scene someoe could have at 60fps. And with what sort of features.