So if a clone is plugged in what does it say
Each operating system acts differently. Mac and Linux don't "say" much of anything. CDC serial devices work automatically and appear as serial devices that can be opened in the normal way. Well, more on linux issues in a bit....
Windows will briefly display the USB device's name, which it retrieved from the USB descriptors (data) in the code running on the clone. So the clone can have any name it chooses.
Even though Microsoft ships CDC serial drivers with every version of Windows, they do not ship any association to actually load them when you plug in the device. In Windows, an INF file (just a text file in a bizarre format only comprehensible to people intimately familiar with 15+ years of Windows
legacy) tells which driver to load. It's much the same as .plist files in Mac OS-X or udev (or hotplug) rules on Linux, except Microsoft in all their brilliance thinks it's a good idea to ship drivers but not actually use them unless the user installs an INF, which isn't much easier than installing a driver (except the developer doesn't have to write the driver, of course).
When you plug any new hardware in on Windows, the New Hardware Wizard will run. Windows 7 actually just uses the INF, if it's already installed, whereas Windows Vista, XP and 2000 make you jump through several steps, to ultimately tell Windows to look in its own directory. If the INF isn't installed, you can use the new hardware wizard to manually specify a location. If you don't and just quit, later when you do install the INF, while you'd think just using it would be the obvious thing, Windows will usually require you to plug the device in again, and go to the device manager and click "update driver".
Anyway, back to what does Windows actually say. Before the INF is associated with the device (which could be quite a while if you quit the new hardware wizard without success), it will show whatever string it could read from the descriptors (data) on the device itself. After the INF is associated (successful new hardware wizard or update driver in the device manager), Windows will show whatever strings were in the INF. Simple, right?
Mac and Linux don't make a big production out of new devices like Windows does. Generally no popups happen. A new serial device just automagically exists, and programs like Arduino that look for serial devices automatically show it in their menus (again, another linux caveat in a moment). However, if you use the system prober on Mac or "lsusb" or look in the log files on linux, you'll see the name from the descriptors read from the device.
So on all 3 systems, what name is seen is entirely up to the hardware, and the INF file supplied with it.
On INF files, there are actually 2 ways they can associate with devices. The most common Microsoft calls "Hardware ID", which is the vendor and product ID (numbers read from the device, entire up to the code within the 8u2 chip). An INF file that uses Hardware ID association will only work with specific vid/pid pairs.
The other INF association is called "Compatible ID". This is similar to what Linux and Mac OS-X do. If ANY CDC serial device is connected, where a set of 3 bytes in the descriptors (again, completely up to the code, but required to be certain values to be considered CDC serial), the driver will associate with that device. The INF file (contained within an installer) that I've been distributing for use with Teensy uses Compatible ID, not Hardware ID. It also gives generic naming. It seems likely the Arduino Team will publish an INF that uses Hardware IDs and very specific Arduino(tm) naming, and probably will not work with any clone (unless the clone copies the vid/pid pair, which this would give them incentive to do). But who knows, maybe they'll use Compatible IDs? That would certainly be the most clone-friendly approach, so a separate INF couldn't be required for each clone.
Now, having talked so much about Windows, which is by far the most problematic system, Linux deserves some mention (but Mac, despite a number of bugs in their CDC driver, usually doesn't require any user intervention to make things work). While Linux will automatically recognize any CDC device (and it's very good at figuring out broken/buggy devices), by default on Ubuntu and most distributions only root (and certain groups like dialout) have permission to actually use it. Usually a udev file needs to be installed to grant permission.
The other trouble on Linux, which is really a problem with the RXTX library Arduino uses to talk to serial devices, is the default name is /dev/ttyACM0, not /dev/ttyUSB0. To the best of my knowledge, no version of RXTX knows about "ACM" (and many others... I made a long list of them all about a year ago, if anyone's interested). So a udev rule is also needed to create a symbolic link with /dev/ttyUSB##. Luckily, RXTX doesn't mind leading zeros, so it's possible to make this play nicely with normal Arduino on the same system. Just look at the udev rules I've published for Teensy for an example.
On Macs, things generally just work. However, the mac CDC serial driver has several minor bugs, such as not supporting break signals, and being completely incompatible with "interface association" descriptors (so you can't make a combo serial+keyboard). Apple may someday fix this... the are supposedly working on it... though it's only been part of the USB standard since 2003.
On all 3 systems, the CDC drivers are not nearly as mature as FTDI. On Windows, trouble with suspend has been reported, and some people just have very "weird" issues. I saw one a month ago where the device showed up in the device manager, could be opened by terminal emulators, but wouldn't talk. Plugging into a different USB port assigned a new COM port number and the same device, on the same system, without even a reboot, suddenly worked perfectly (this was Windows 7, btw).
The overall user experience with CDC just isn't as refined as FTDI.
But as for what's displayed, the code running on the 8u2 chip and the contents of the INF file completely determine what text the user sees.