Whether you use "Windows Forms" or "WPF" is usually determined when you create a new Visual Studio project: i.e. choosing Console; Windows Forms; WPF; etc. when you create a new project.
WPF has been around for a while, but since I have only been using it from 2008 on, I don't know how 2005 supports it.
Anyway, if you're limited to 2005, create a new project in VS, and if you have the option to create a WPF project, then you're good to go (unless "the powers that be" insist you use only Windows Forms).
I don't know how much this software will morph over time, but the only other special thing I will need to look into is a "console" window on one of the tabs of my GUI to take manual commands as things are running.
Outside of that, my best guess is that the "drawing circles" is the only quirky feature I need to have for this GUI that isn't obvious on the standard C# toolbox.
Am I better off doing this on Visual C++ or Visual Basic?
Only if you have more experience with either of those languages, although the issue is exactly the same whether you use VB.NET or C#. My original suggestion to use the graphics class is still your best option.
You assume too much. If the OP was prepared to use WPF, I would have posted a solution that any "noob" would have understood.
Any solution (in this case) that is at least object-oriented is superior to one that simply "draws".
The OP is creating a UI (not some scribbles); and creating "leds" implies managing "state" (i.e. on/off); image controls (the OP's thinking), "shapes", etc. are a lot more useful in this case than simply "drawing" (as you are suggesting).
In my opinion this (or using XmlReader directly) is the way to go:
Consistency - the web service uses xml responses because it is a standard with some pros e.g. extensibility and formatting. By not parsing xml according to the standard, you don't get the benefits from the standard.
Performance - XmlElement.parse is built upon XmlReader which is a sequential reader. It is both faster and cheaper in memory than XmlDocument that builds a complete DOM in memory.
But since you are doing nothing but a simple value lookup what you are doing is probably the most performant (although probably not in a significant way.)
There are upside/downsides to ignoring the XML itself. For example if they change element names on the message your code still works. But if they add another element first with a numeric value it doesn't.
Conversely using XML if they change names then the code would fail. But if they add another element it would still work.