Not a big problem. Just scale up the terrain, even beyond camera far plane, or scale down the plane. The first flight simulator I have seen was GunShip for Comodore 64. A “hill”, one mile by one mile, has been a pyramid made of 5 vertices! And I don’t know if I ever spent so much time playing a single game like I did with GunShip. And the sky-dome, well, keep it small (as big as your visibility distance), and move it together with the plane or camera (in horizontal direction, but not vertical). Of course your terrain will look a bit simple, but you can do any size of terrain if you keep detail low.
The problems start when you want to have high detail AND large terrain. And you are pretty much on your own from now on, afaik.
First, you won’t be able to keep all your terrain data in memory (a few hundred megabytes or some gigabytes), so you have to load and unload parts of your terrain while you fly around. Out-of-core and paging are the words to search for.
Since a flight simulator doesn’t need unique terrain details you could also procedurally generate some “detail” information for your low-resolution terrain data (perlin noise, detail textures, …).
Then, perhaps, you want to save a few vertices and render distant terrain chunks at lower resolution than the terrain directly below you. So you have to decide for a way to do LOD. Geo-mipmaps is the best I know at the moment, but there are a dozen more.
Then you want to optimize even more, and consider the camera frustum and perhaps hide parts of the terrain which are not visible from the current position, perhaps a valley behind a mountain (potentially visible sets, offline calculated).
Oh, and huge terrain doesn’t only mean huge landscape, but also huge numbers of trees, vegetation, buildings, mobile objects and so on. You have to load/unload these objects too (and perhaps activate/deactivate, if there is logic tied to the 3d models). So perhaps it is possible to design your game code with this in mind, and load/unload terrain chunks TOGETHER with the objects on this chunk in one go, at the right level of detail.
And finally popping, well, I have read that hardware geomorphing (in GPU) is a good way to avoid popping. Lighting can hide the effects of popping, and you don’t need normals/binormals/tangents stored together with mesh data. For example a normal-map (bitmap, with vector coordinates stored in r/g/b channels) will do too, and can be created offline using the highest possible resolution of your terrain.
So, after being mean here is my real advice: Lean back and think about your requirements. What terrain features do you really need? What are your resources (hand-modeling huge terrain will cost you more time and money than Betheda had on their Oblivion budget). There is no solution that suits every project.
Hope this helps
enn0x