Sorry, I haven't written up the file format for the elevation files yet, but I will do so for one of the next betas. For now, you may be able to guess how it's arranged from the read function at
http://sourceforge.net/p/orbitervis/code/HEAD/tree/D3D7Client/surfmgr2.cpp#l125.
Essentially, it's a binary file containing a header and a 259 x 259 grid of integer elevation values (8 or 16bit).
Each file contains the elevation data for a tile at a given resolution, covering a certain latitude and longitude range. The tiles are part of a quad-tree, whose root contains two tiles (western and eastern hemisphere), at resolution level 4 (levels 1-3 cover the entire surface and are not part of the quadtree). Each subsequent resolution level is constructed by splitting a tile into 4 subtiles.
The data represent a 257x257 node grid to construct a mesh covering the tile, plus padding of one row of nodes on each side (i.e. each tile shares 2 rows of nodes with each of its neighbours).
The naming convention is
Textures\<planet_name>\Elev\<level>\<latidx>\<longidx>.elv
where <level> is the resolution level (2 digits), <latidx> is the latitude index (counted north to south) and <lngidx> is the longitude index (counted west to east).
You don't need to provide all tiles at all levels down to the maximum resolution. The only requirement is that the data files for the two root tiles exist, because each tile needs to have a valid set of elevation data somewhere in its ancestor branch to interpolate from if it hasn't got its own data. So you can provide regional high resolution elevation cover by just inserting the files for the relevant tiles.
