One vertexbuffer per level is not necessary.
I did s.th. similar. I have one central mesh, one ring mesh and one transition mesh (also a ring but thinner), the latter two being rendered multiple times with different scales. The memory impact is negligible but since all meshes are always visible, you loose the ability to frustrum cull the terrain behind the camera. On the up side, you have fewer drawcalls.
If I find the time, I'll try to rearrange the indices in the indexbuffer in a way, that I can render only specific index ranges in each ring, where each index range corresponds to one section of the ring. That way, I should gain the ability to frustrum cull the terrain, but without needing significantly more draw calls (at least when the index ranges can be merged).
Ah yes, of course - one vertex buffer is only needed + one for the center. But yes, of course - you loose the ability to do frustum culling. Interesting idea bout the index buffers tho and to do frustum culling through that.
I can't notice how much different this approach is from, say, a quad tree based LOD. Unless I am missing something...
Well, compared to something like a quad-tree based geo mipmapping which is usually done on the CPU, this has a few benefits:
1) All of the heavy computation is done on the GPU
2) A lot less draw-calls