Terrain CLOD: A properly implemented CLOD algorithm still beats the pants off a brute force system. This is due to the shear volume of geometry that a terrain contains. If you only render 10% of it, then your card is free to do other things. Not to mention the market penetration of T&L cards is still miserably low (give it another year…).
Texturing: It would be nigh-impossible to texture a terrain properly with auto-gen tex coords. Too many edge-blending issues. And a good texture LOD algorithm looks fabulous compared to a detail texture over a super-streched color map.
TIN: Too complex, too much memory, too many ‘sliver’ triangles…
VIPM: Why? Isn’t ‘View Dependent’ the whole point? shrug Depends on the project I guess.
VDPM: Looks promissing, I need to read more. 
Geomip-mapping: Does not allow for strong terrain roughness metrics. Works fabulously for ‘smooth’ terrain though. Try it with ‘spikey’ terrain and you’ll understand.
Finally, robert_s: You do not need to draw the wireframe for any of the terrain. Instead, you want to draw only those parts of the terrain in the view frustum. Read my Gamasutra article to get an idea of the terminology used in Terrain Rendering. You’ll be performing two phases: Tessellation and Rendering. During Tessellation, you decide which areas of the terrain to render, and how many triangles to use for it, this decision is called the Split Metric - and is also where you perform frustum culling.
I keep a fairly up-to-date bibliography of Terrain Rendering on my website, I recommend purusing it before beginning your engine. (http://www.fractalscape.org) Also check out the cannonical site (http://www.vterrain.org).
–Bryan