As i see it, there is no reason why it shouldn’t be possible to use NURBS or (most preferably) subdivision surfaces directly and use a subdivision process as Rhino, Maya and most other software do. The math is just as well defined as for mesh calculations and not really harder to implement. Meshes are good but limited and resource consuming. NURBS and SubD has been the industry standard for a decade in bigger apps. It is time that DAZ takes this into consideration.
The OBJ file format (which is ultimately how all geometry initially makes it into Studio) doesn’t natively support NURBs. (There are, I believe, some vendor-specific extensions to do so.) Even with plymesh being an extensible format, I don’t know that any tools read NURBs from it. LuxRender, for example, does not. The only way to specify NURBs in LuxRender is in-line in the scene file. And LuxRender internally generates a triangle mesh from the NURB in order to render it.
Subdivision, however, IS natively supported by Studio. It uses the Catmull Clark algo for it. Any object can be converted to SubD. Select the object in the scene tab, click the corner menu and then Edit->Convert to SubD. Some stuff, such as Genesis, loads with subdivision already enabled. The one silly thing about SubD in Studio is the levels of subdivision has a default parameter lock of a max of two levels. Depending on your shape, that may not be enough. You can unlock the parameter (gear icon) and then specify higher levels. However, there is currently a bug where the unlocked state is not saved, so when you reload the scene, it goes back to a max of two and will reduce any objects that were higher than two back to two as well. (Bug entry 49068)