Correct. If the driver does not adhere to the interface which the UVC drivers (which come with USB, but are not exactly USB drivers), then some other naming convention would be used. Whether or not you can use it just depends on the driver.
There is a constant reminder in any literature you read about code development on any UNIX style system (anything following the POSIX standards…UNIX is just a trade name) that “everything is a file”. This includes hardware devices accessed through files. Base access, if supported, can be performed on all of the drivers via open/close and read/write operations common to an ordinary file.
Some drivers have customization because they need more than basic file operations. Any calls to a driver which do not adhere to the standard file operations instead use an “ioctl” (I/O control) interface…a variable argument list of custom functions (not unlike the C variants of the printf function which handles any number of arguments via a variable argument list). The ioctl is called against the file descriptor just like ordinary file operations, but failure to support this in the driver will result in an error. There are cases, such as the video devices of the UVC drivers, where a large number of video device manufacturers have chosen to give the same ioctl and basic file operations as the method of operating their device. If the two devices use a driver which implements the ioctl and basic file operations in the same way, then the programs which use the one driver can use the other driver (and hardware behind the driver) interchangeably. Perhaps some program made some requirement for a certain name convention in what device special file naming convention is allowed, but in reality compatibility depends on the ioctl interface and file interface and is not dependent upon a device special file (pseudo) name.
It also would not be uncommon for a device to work with a given class while also extending that class. As a contrived example, suppose your camera is UVC. Now assume the camera has a built in light to use for flash, and that light can operate at either thermal or visible light range. That extra control needed would require extra ioctl driver additions, but the rest of the camera could operate just like any other UVC camera. Any generic driver would be able to load and use the basic camera, but you would need special software to operate the light. Special software for that camera would have no way to do anything new to any other standard UVC device, but would probably be able to run basic camera operation for some other manufacturer’s UVC camera.
When a USB device is plugged in the device is queried and the nature of the device is broadcast to drivers so that qualified drivers can see if they want to take ownership. In the case of the verbose USB plug in details (“sudo lsusb -vvv” shows this…which can be limited to a single device via the ID using the “-d whatever:whatever” ID) picking a driver to load depends on what the device advertises during its capability query. The device could respond with more than one capability, e.g., a custom lighting control plus a standard camera. The standard camera most of the end user software expects to see is a UVC device because it is a published standard which an enormous number of devices follow. With no such declaration from the camera that it is UVC the camera must fall back to a custom driver and no “standard” driver will work (this is true even if the camera is otherwise UVC compliant because the broadcast of the device type doesn’t tell the UVC drivers that they will work).
If the end software checks that the device is UVC class, then a non-UVC camera might be rejected even if the file and ioctl interfaces match. On the other hand, a program which only checks for certain functionality via those interfaces will work regardless of whether the device is UVC or custom (the software might “probe” to see the response of the ioctl to determine support). If a manufacturer of software intends their software to only work with USB devices, then simply refusing anything not explicitly broadcast as UVC would occur. On the other hand, there are many devices which need to function under both PCI and USB, in which case the software might be more sophisticated and check the interface compatibility through some form of probing instead of something more generic.
Since your camera does not broadcast its capabilities as UVC, then no standard UVC driver can take ownership. A custom driver knowing about this device would chose to load and create the “/dev” pseudo file (the name of which is up to the driver and perhaps the udev system renaming it). If the custom driver implements the same file operations and ioctl calls on that device special file, then UVC programs could possibly work if forced to use the device special file.