How does a web GUI work on network devices like routers and switches
and what kind of skills do developers need who make these interfaces?

You need someone with these skills:

1. knowledge of the language used to program your hardware, probably C or C++
2. working knowledge of the HTTP protocol
3. good with HTML

Number one on the list is the most important, obviously.  It can be
hard to find people who have this skill and are also good at HTML
(#3), which is probably why most hardware HTTP web GUIs are so clunky.
 A person with both is an artistic engineer--not a usual combo.  HTTP
knowledge (#2) is useful but not critical since most anyone can refer
to the RFC for the HTTP protocol and figure out how to handle a GET or
POST (page request from the browser).  HTML (#3) is crucial if you
want the interface to look professional and work cleanly.  I'd start
by making a list of the functions that need to be performed in the
GUI.  Get a graphic artist or web designer to mock up the GUI
interface.  Tell them to use very minimal images, no JavaScript, no
DHTML, no frames, no linked stylesheets, no meta tags or other
clutter, and verify similar appearance on multiple browsers.  This can
be done for fairly cheap.  Then get a good programmer that can work
from the HTML mockups.  This will give the programmer a
"specification" to work from and you'll know what to expect from them.
 You could try to find someone who can do it all.  That person will
probably cost a lot more than a regular programmer, enough so that
they will cost more than paying for a separate graphic artist and
programmer.  The programmer may have issues with some of the HTML
designs given memory limitations and so forth, so you may have to do a
little back-n-forth to get a design that is professional and feasible
for the programmer.

So how does the html interact with the C or C++ code? Where can I get
more informtion on this?

Let's walk you through a simple session.  I'll leave out
authentication and that sort of thing because it's too complex for a
simple example.

The user navigates their browser to http://192.168.1.1/setup.htm (for example).

The browser requests to open a socket connection on port 80 with the
hardware.  This is done automatically by the operating system and
browser.

The hardware has a program that is "listening" on port 80 (the default
port for HTTP) for socket connection requests.  Once it gets a
request, it opens the socket and waits for commands, HTTP commands in
this case.  "Opens" in this sense really just means notes for itself
the IP address of the connected computer and allocates any resources
necessary to handle subsequent HTTP commands.  You could use a port
besides 80, like 8080 and the corresponding URL on the browser would
be http://192.168.1.1/setup.htm:8080

The program running on the hardware is probably going to be written in C or C++.

Once the browser has established a socket connection, it will send an
HTTP command to GET the file setup.htm.

The program on the hardware receives the HTTP command and sends back
the text of a file to the requestor.  The file is just text, but is in
HTML, meaning it has tags in it, like <b>this is in bold</b> or
<h1>Hello User</h1> or <button>Save</button>.  The program on the
hardware also has to read the internal settings of the hardware (by
reading values from its memory or other storage device) and substitute
that information into the HTML file it is creating to send to the
requestor.  So the HTML starts as a template and the program on the
hardware substitutes in the values of the current settings and sends
that back to the requestor (the browser).

The browser gets the HTML and displays it.  This is just what browsers
do and exactly how is of no concern to you in this situation.  The
HTML that makes up the page can be designed to cause the browser to
draw text boxes and buttons that allow the user to type text and then
press a Save button.

When the user submits the information he has typed by pressing the
Save button, the browser sends an HTTP command to the hardware again. 
This HTTP command will contain all of the information that the user
typed on the page, as well as a request for a new copy of the HTML
page that he was viewing.  Again, this is just what browsers do and
requires no intervention or coding on your part.

The program on the hardware gets this HTTP command, extracts the bits
of information typed by the user, determines what to do and then makes
corresponding changes to its internal settings by writing new data to
its memory (or long-term storage) to implement the user's requests. 
With this done, the hardware program must now generate a new HTML page
by starting from its HTML page template and substituting in the values
of its internal settings to make the page reflect the new settings. 
This new page is sent to the requestor (the browser).

The browser gets back the new HTML page and displays it.

This cycle goes back and forth until the user completes his
interaction with the hardware and disconnects or navigates away.

The browser sends a socket disconnect request to the hardware.  The
program on the hardware notes this and reclaims any resources that
were allocated to handle the HTTP commands.

So the hardware will have an html directory and any images associated
with the GUI would be stored there? Do you know of any examples where
Flash is used to create the GUI on hardware? ?Is this even possible?

Yes, exactly, the hardware will contain a directory with HTML
[template] files and images.  I don't know of any examples of Flash
being used with this kind of GUI, but it is certainly possible.  Flash
files will just go into your directory with the images and HTML files.
 If you use Flash, you'll want to keep a few things in mind.

Use of Flash in the GUI requires that the Flash plugin be installed on
the computer with the browser that is using the GUI.  If the plugin is
not installed, then the GUI will not work.  The HTML page that has
embedded Flash can tell the computer where to go to get the plugin if
it is not already installed, but if that user is not connected to the
Interenet, they won't be able to get the plugin.

You might be able to put the Flash installation files on your hardware
so the user can get them directly from your hardware while using the
GUI.  You will need to make sure that this is not an infringement of
Macromedia's licensing, as they may require that all installation be
performed from their website.

If you are trying to achieve maximum usability, Flash may not be the
best approach.  I'd try JavaScript/DHTML before using Flash.  You can
do a lot with rollovers and DHTML events and unless you try to do
complicated things, most of it can be written to be supported by all
of the major browsers.

Thanks so far for all your input willcodeforfood. 

I?m ?uh well it?s basically daydreaming about taking a router made in
Taiwan and having the entire management interface redone (because
theirs is crap) but based on you responses it looks like I would need
the hardware (C or C++) source code to do this. Is this correct? If so
would it be possible for the GUI to initiate scripts that execute
commands into an existing CLI (to get around not having the source
code)?

Even if you had the source for the router's firmware, it probably
wouldn't do you any good.

Using the CLI as an interface is definitely an alternative.  You could
use a separate machine with a web server to host the GUI.  You'd get
the info from the router by reading it's config files or piping the
output from a telnet session (with the router) to disk.  Once a user
"saves" their changes, you would write a telnet script file to a
directory. When run, that script would use the CLI to connect to the
router and make the necessary changes.  You could even pipe the output
from the script into a file and parse that file to verify your
changes.  Start by writing one command script to make a change to each
individual setting,  just substritute into that script the user's new
parameter and run it.  If the user makes three changes, run three
scripts.  It should be pretty fast.  The only real issue that I see is
security, since the script file will have to have the router's
password in it.

A decent web/software programmer could probably do the job in a month
or so.  If the router is a common model, you could always put out a
bid on rentacoder.com and see how much someone would be willing to do
your job for.  Good luck.

The beginning of your last commenmt: "Even if you had the source for
the router's firmware, it probably wouldn't do you any good." -why is
this the case? Would it be too difficult for one group of developers
to understand what another group of developers has done?

If the router was not designed to support a HTML GUI in the first
place, you'd likely have to entirely rewrite the firmware.  There may
not even be enough storage capacity on the device to hold the HTML,
image files, and new software.  I'm guessing it'd be a bit of a
frankenstein job.  On the other hand, you might get lucky and find
that the firmware can be made to do what you want with just a little
tweaking, but I wouldn't hold out too much hope.  If you are seriously
considering overwriting the device with your own program, find someone
with more familiar with firmware to give additional feedback.