Hello and welcome! Sounds like another interesting project is on the way and it's always nice to have new users

Seems like you have a good idea what you are looking for so I'll do my best to clear up your questions...
Shanee wrote:
MLE is using DirectX 9, I saw the example uses OpenGL. As far as I know the OpenGL and DirectX triangles/indices are pretty much flipped, aren't they? Can I just copy the vertices and indices given by the SurfaceExtractor to my DirectX vertex buffers and index buffers as is?
It's no problem. The demo does use OpenGL but other people have used Direct3D. Personally I use Ogre, which has an abstraction layer allowing either Direct3D or OpenGL to be used behind the scenes. But PolyVox is independant of the graphics API you use. You are correct that the default winding direction for polygons is the otherway around in Direct3D, but it is possible to change this. Or, you can tweak the index buffers by swapping the second and third index of each triangle so that e.g. 1,2,3,4,5,6 becomes 1,3,2,4,6,5
Shanee wrote:
Second question, I tried to look but didn't find much (btw parts of the manual seem to be broken?) - How does LOD work here? and I heard there were some issues with holes?
There is not much in the way of LOD because I personally haven't had much need for it. There is a MeshDecimator class which will take a patch of terrain and reduce it's triangle count so that it is just an approximation of the surface. It does not introduce any holes but there is a limit to how far you can go with this.
Alternatively you can use several volumes at different resolutions. However, in this case there tends to be a slight mismatch between the generated meshes because the different resolution volumes cannot line up perfectly (these are the holes you have heard about). In the last few months a technique has been developed to address this (TransVoxels) but PolyVox does not implement this yet. It probably won't get implemented for a few months (at least by me, you could always implement it yourself).
Shanee wrote:
Question number three, texturing. How do you get the UV on the surface?
There are no UVs generated because there is no good way to do this (at least that I know of). Instead, for smooth terrain an approach called triplanar texturing is usually used. You can read about it
here and I can answer questions about it. A similar appraoch can be used for Minecraft style terrain. On that topic, what style of terrain are you looking for?
Shanee wrote:
Last but not least, question number four! I saw the videos show real time editing of the voxels, how will this apply for terrain? Does it mean you should use relatively small "volumes" so when updated the vertex buffers are easy to update? What sizes of voluem should I consider?
You can use a single volume, but conceptually divide it into regions with a mesh generated for each region. Then, when a voxels changes you only have regenerate the mesh for that region (as you describe). Some people are using multiple volumes so that they can page them to disk to simulate infinite terrain etc, but this introduces some complication you should avoid to start with. Any idea how big your terrains need to be?