Hull & Domains
The hull and domain shader stages are part of the tessellation pipeline of the GPU. They're generally used to compute highly-detailed surface geometry based on lower-detail input surface geometry, which is defined as triangles or quads (et cetera). The lower-detail input primitives are called "patches," and it's important to note that they may not represent actual geometry that will eventually exist (although they could). Think of more like the control points of a bezier curve, except for a surface.
The hull shader takes an input patch and produces an output patch (or patches; this is where subdivision of the patch would generally occur). Constant metadata about the patch can also be computed within the hull shader and output for processed by later stages of the pipeline.
The output of the hull shader runs through a (fixed function) tessellation stage which produces tiled, normalized domains of the appropriate type (e.g., quads or triangles).
The domain shader is executed against these domains in order to compute the actual vertex position of any given point in a domain that resulted from the aforementioned tessellation. The domain shader thus outputs a vertex position.
The tessellation phase occurs after the vertex shader stage in the pipeline.
Geometry Shaders
Geometry shaders are like simplified hull/domain shaders, in a way. They simply take input vertices and produce output vertices. For a given input vertex, many output vertices can be produced, so they can be used to "generate geometry."
The geometry shader stage occurs after the vertex shader, and after the tessellation stage.
Uses
The geometry shader can write to stream output buffers instead of being fed directly into the rasterization and fragment shading phase of the pipeline; this effectively means you can re-run the geometry produced by a combination of a vertex/hull/domain/geometry shader iteration back through the pipeline, to perform additional work in another vertex shader stage or whatever.
What you can use these for is a rather broad, effectively-unlimited topic, so I won't really attempt to address that. But as for some motivating reasons to consider using them... The big thing about these shader stages is that they let you get a potentially quite a lot of extra detail without paying the memory or bandwidth cost for all of it, all the time. And also to move processing from the CPU to GPU.
Terrain is a good example of where you might want to use some of this technology, as you generally need to see it both very close (as your character is standing on it) and very far away (the mountains in the distance) and being able to control where and how much detail you put into the terrain geometry "on the fly" via these shader stages is very powerful. The alternatives have historically been either paying a constant average cost for the terrain at all times (a lowest-common-denominator approach) or manually paging chunks of geometry for different levels-of-detail in and out of GPU memory, which is tedious and expensive.
Any similar situation where you might have a really broad range of levels-of-detail you need to support for some mesh or model that is also reasonably subdividable may be a candidate for doing something clever with these shaders as well. Not everything translates well to subdivision surface style optimization, though. You could probably use them for cloth and hair as well.
For further reading, including vastly more detail than I can reasonably remember or go into here: