No big deal, and too bad.
Though not viable for everyone, it would at least have been an option for some very select situations.
If you are still at it, I suggest making a fully custom system.
Because in a procedural mesh the positions of the vertex are known (x/y being constant) you can save data by just passing in Z.
The tris order is always
Up Left
Down Left
Down Right
Up Right is ways = to Up left, and down left is always the same as down right when you move to the next instance.
As such, a comma separated list of Z values can easily be enough to generate the whole landscape with Zilch in terms of storage cost.
(Should be called a triangle strip system if i remeber correctly).
If you really want to gut things to nothing, the other data stored is the normal.
You can easily represent it with 2 int16 values.
(Dont think the engine will know what to do with it, but ao long as your math sets the normal to what it should be then the engine is only aware of the normal. Not of how you store and use the data for generation - again, the issue here is generation and the sheer amount of data it requires).
The benefit of making somerhing like this would basically be the ability to stream in an endless line of vertex to continually generate new strips…
Onviosuly you srill have a bottleneck on rendering/amount of tris.
So you need to come up with some sort of aggregation or tiling system.
Unlike Epic’s mess, which does it with some low level mipping (deletes your data at a diatance on a /2 scale with each LOD)
I would suggest finding different and Analytical approaches.
Just like you can simplify a ton of different ways, having a 0 in the data stream for any vertex Z that is below a height requirement treshold would probably net some interesting simplification results (but still use all the verts).
Removing the verts analytically that’s where the real magic happens…