OptixWhitted: how to insert scene from OPENNURBS ON_Mesh?

I wouldn’t recommend using the optixMeshViewer example as basis in that case. It’s tailored to the GLTF file format requirements and is not actually handling the full GLTF spec.
That the BufferViews inside the MeshGroup class assume specific template types for the GLTF attributes is one of its shortcomings. That won’t always work.
The MeshGroup class is also specifically handling the GLTF’s way of defining a Mesh as multiple Primitives (each matching a draw call in OpenGL) where each primitive can have a different Material (which is also the reason for that aabb_input_flags array). That’s why the geometry acceleration structure build is using multiple build inputs and one SBT entry for each of them.
That would be much too complicated for the things you asked for.

Are you planning to intersect NURBS primitives directly or is that ON_Mesh already tessellated to triangles?

In the latter case, you should look at examples which are using built-in triangles in OptiX and generate geometry acceleration structures (GAS) from that and build scenes by putting these under instances inside an instance acceleration structure (IAS). The traversable handle of that is your scene’s root you use inside the optixTrace calls then.
The optixWhitted example is also not doing that. It’s only showing some hardcoded custom primitives.

The introductory examples in my OptiX examples described here
https://forums.developer.nvidia.com/t/optix-advanced-samples-on-github/48410/4
build a scene by creating some runtime generated shapes (plane, box, sphere, torus) using indexed triangles and an (interleaved) vertex attribute array on the host.
Then the vertex positions of that are used to build GAS with built-in triangle geometry.
https://github.com/NVIDIA/OptiX_Apps/blob/master/apps/intro_runtime/src/Application.cpp#L1361
(Note that the GAS are not using compaction, yet to keep the introductory examples simple. That is shown inside more advanced examples of that repository later and is recommended.)

These GAS are put under OptixInstances to place them into the scene:
https://github.com/NVIDIA/OptiX_Apps/blob/master/apps/intro_runtime/src/Application.cpp#L1598

Then all these instances are built into an instance acceleration structure:
https://github.com/NVIDIA/OptiX_Apps/blob/master/apps/intro_runtime/src/Application.cpp#L1705

That example is using interleaved vertex attributes.
https://github.com/NVIDIA/OptiX_Apps/blob/master/apps/intro_runtime/shaders/vertex_attributes.h
If your vertex attributes are separate arrays instead, you would need to change the GeometryData structure from using one CUdeviceptr attributes to the four arrays you have.
That would obviously also require to change all accesses to these inside the device code.
Also if you don’t use indices, that would need to be changed everywhere the geometry primitive index is used during AS build and vertex attribute accesses.

I would recommend to start with a new project from scratch for your case and only copy and adjust the example code handling the geometry first.
Then implement some ray generation, closesthit and miss programs which can hit/miss your geometry with the simplest possible shading, e.g. only showing object space normals as colors and a constant background color in the miss shader.
Only when that is working, implement some more elaborate lighting and shading routines.
The most advanced example in this repository goes as far as using a full blown Material Definition Language (MDL) based material system.

The examples are also showing different ways how to design the shader binding table (SBT). While the initial programs use a hit record per instance with SBT pointer data, later examples like rtigo10 and the MDL_renderer use an SBT with one hit record per material shader and use the user-defined OptixInstance instanceId field to reference any additional data per instance.

Now if the plan is instead to intersect NURBS geometry directly with a custom intersection program you would need to implement first, then all the built-in triangle geometry acceleration structures would need to be replaced with the AABB around these NURBS primitives for the optixAccelBuild inputs and then a shader binding table with hit records using that custom intersection program as well.