I used to have a single vertex buffer for one page/patch of terrain, then each block in the terrain system would contain its own index buffer that pointed into the vertex buffer. The quadtree divides down so that each leaf of the tree points at one block of the terrain, and frustum culling occurs at that point. (I just fixed terrain frustum culling once and for all yesterday finally.. the axis-aligned bounding boxes were not calculated correctly before, which resulted in incorrect frustum culling).
One problem with having a single vertex buffer was that the entire terrain system was limited to 65k vertices, which means a 256x256 heightmap since we require the heightmap to be square in shape. You could always load multiple terrain systems at a time, but that didn't make sense. The new system provides ample vertex space, setting the limit to 65k vertices per terrain block (which is, of course, way too much). For my tests, I'm dividing my terrain blocks down to 4096 vertices each.
Well, on paper those are the numbers. One problem that came up is the obvious disconnectivity in the index buffers between the various blocks. The index buffer of one terrain block cannot contain triangles that connect vertices from one vertex buffer with vertices from another. The result looks something like this. Those gaps are due to the index buffers not connecting. Each block is 64x64 vertices, and the entire system is 256x256.
So the solution is to add a little "buffer strip" along the edges. A block needs to have 65x65 vertices, such that row 65 of both axes is set to the same position as rows 0 of the neighboring block, and they look like they're all one mesh. That looks like this. Much better.
But for other purposes, I don't want the heightmaps to be non-power-of-two images. I still want the same heightmap. I ended up making the terrain systems internally add the extra buffer vertices, while the user of the engine still sees the terrain system as being 256x256. Any queries to sizes will tell the user the size based upon heightmap calculations, so it's slightly inaccurate. I thought this was a trivial trade-off, though.