An AMI, as you note, is a machine image. It's a total snapshot of a system stored as an image that can be launched as an instance. We'll get back to AMIs in a second.

Lets look at EBS. Your other two items are sub-items of this. EBS is a virtual block device. You can think of it as a hard drive, although it's really a bunch of software magic to link into another kind of storage device but make it look like a hard drive to an instance.

EBS is just the name for the whole service. Inside of EBS you have what are called volumes. These are the "unit" amazon is selling you. You create a volume and they allocate you X number of gigabytes and you use it like a hard drive that you can plug into any of your running computers (instances). Volumes can either be created blank or from a snapshot copy of previous volume, which brings us to the next topic.

Snapshots are ... well ... snapshots of volumes: an exact capture of what a volume looked like at a particular moment in time, including all its data. You could have a volume, attach it to your instance, fill it up with stuff, then snapshot it, but keep using it. The volume contents would keep changing as you used it as a file system but the snapshot would be frozen in time. You could create a new volume using this snapshot as a base. The new volume would look exactly like your first disk did when you took the snapshot. You could start using the new volume in place of the old one to roll-back your data, or maybe attach the same data set to a second machine. You can keep taking snapshots of volumes at any point in time. It's like a freeze-frame instance backup that can then easy be made into a new live disk (volume) whenever you need it.

So volumes can be based on new blank space or on a snapshot. Got that? Volumes can be attached and detached from any instances, but only connected to one instance at a time, just like the physical disk that they are a virtual abstraction of.

Now back to AMIs. These are tricky because there are two types. One creates an ephemeral instances where the root files system looks like a drive to the computer but actually sits in memory somewhere and vaporizes the minute it stops being used. The other kind is called an EBS backed instance. This means that when your instances loads up, it loads its root file system onto a new EBS volume, basically layering the EC2 virtual machine technology on top of their EBS technology. A regular EBS volume is something that sits next to EC2 and can be attached, but an EBS backed instance also IS a volume itself.

A regular AMI is just a big chunk of data that gets loaded up as a machine. An EBS backed AMI will get loaded up onto an EBS volume, so you can shut it down and it will start back up from where you left off just like a real disk would.

Now put it all together. If an instance is EBS backed, you can also snapshot it. Basically this does exactly what a regular snapshot would ... a freeze frame of the root disk of your computer at a moment in time. In practice, it does two things different. One is it shuts down your instance so that you get a copy of the disk as it would look to an OFF computer, not an ON one. This makes it easier to boot up :) So when you snapshot an instance, it shuts it down, takes the disk picture, then starts up again. Secondly, it saves that images as an AMI instead of as a regular disk snapshot. Basically it's a bootable snapshot of a volume.

Background

Launching an Instance from a Snapshot is not available for Windows AMIs (as you have meanwhile discovered yourself):

Important

Registering a snapshot works only for Linux/UNIX AMIs; although you can register a snapshot to create a Windows AMI, the AMI isn't launchable. [emphasis mine]

Alternative

While not specified, one should be aware of the possibility to simply clone an Amazon EBS-Backed Instance as outlined in Creating an Image from a Running Instance - when doing this via the AWS Management Console like so, EC2 attempts to cleanly shut down the instance before image creation and reboots the instance afterwards. This is obviously generally preferable, however, it can be avoided via the command line, if so desired:

If you prefer the instance not be rebooted, you can use the Amazon EC2 command line tools to create the image [...]. The ec2-create-image command has a --no-reboot option.

Solution

The alternative approach mentioned above obviously won't help to create a new EC2 instance from one of these snapshots as specified - a solution useful to be aware of anyway is outlined in section Moving to a New Instance of Eric Hammond's article Move a Running EBS Boot Instance to New Hardware on Amazon EC2 (which has a different use case, but applies regardless) and boils down to these steps in your case:

1. Create a new instance with the same startup parameters as the original one.
2. Wait until the new instance is running and then stop (not terminate) it.
3. Detach the EBS boot volume from the new instance and delete this detached volume, as it is not required anymore.
4. Create a new volume from the snapshot and attach it to the new instance.
5. Restart the new instance which is now going to boot with the volume created from your snapshot.

This technique has been used by Colin Percival to enable running FreeBSD on EC2 via defenestration as well btw. (which includes some hints towards the virtualization issues):

EC2 Windows instances, on the other hand, are launched in HVM (Hardware Virtual Machine) mode — which FreeBSD supports very well. If we can somehow trick EC2 into launching FreeBSD the same way as it launches Windows, we can run FreeBSD on a wide range of instance types. How can we trick EC2? Take advantage of the fact that Elastic Block Store disks can be detached from EC2 instances and reattached to different instances, and replace the boot disk of a "Windows" instance with a disk containing FreeBSD.