EvilSOB's idea of a single-frame object shader to handle the painting with height calculations is totally doable and would be very quick.
Alternatively, you could re-think your use of get_height -- you may want to have a height_init function or something that prepares a terrain for height calculations, and then a new get_height function that uses data from height_init:
The c.v pointer points into the mesh vertex buffer, which is an array of D3DVERTEX structs with a total size given by ent_status(ent,1)*ent_status(ent,22) . Calling ent_getvertex(ent,NULL,1) followed by ent_setvertex(ent,c,1) retrieves a pointer to the start of the vertex buffer, and allows to modify the whole vertex buffer without further ent_getvertex or ent_setvertex calls. However this fast method only affects one mesh chunk of multi-mesh entities, and the row/column order of the vertices in the buffer correspond to the chunk size in that case, and not to the whole terrain size.
Direct manipulation of the data should be quite a bit faster, although it's still a lot to do for the CPU and I definitely recommend exploring the pure shader-based option.
I hope this is helpful -- I haven't read the whole thread.
EDIT -- I didn't realise EvilSOB had already covered the ent_getvertex optimisation as well.
