Assume running a vertex shader is 100 flops, then that means you can process 1000e9 / 100 = 10e9 vertices per second.
No, it most assuredly does not.
Basically, you should consider any calculation of the execution speed of any code based solely on "FLOPS" count to be suspect. Indeed, it's generally best if you completely ignore FLOPS entirely.
You did not define the term "parallel unit"; without that definition, we could only guess at what you're wanting.
Take the Radeon 5870. It has 1600 floating-point units. That means, for every cycle, it can be executing 1600 scalar floating-point operations at once. However, each VLIW opcode works on 5-way vector math registers. So the smallest possible granularity of actual code is 1600/5, or 320 (note: this is a vast simplification). That's 320 threads.
However, that's not really how it works. You don't have 320 separate paths of execution going on. You cannot have 320 different pieces of code executing on 320 different units. See, the 5-way VLIWs are themselves grouped into 4-way SIMD cores. Each SIMD can have its own path of execution and its own source code. Each VLIW within an SIMD core can have separate data, so that they compute separate values. But each VLIW within an SIMD core executes the same instructions in lock-step with the other VLIWs in that core.
So really, you only have 320/4, or 80 total threads. But again, it depends on what kind of "parallel unit" you're talking about. Technically, 1600, 320, and 80 are all legitimate answers.
And that's just for one specific architecture. NVIDIA's Fermi line (GeForce 4xx and above) uses a vastly different architecture. ATI's Cayman line (Radeon 69xx) changes the 5-way VLIWs to 4-way VLIWs. Their next architecture may have some significant differences too.
Without knowing what you're looking for, there's just no way to answer the question.