<p>I'm thinking about exploring the idea of having our client software run as a service on a high port and listen for simple http GET requests from 127.0.0.1.  The theory is that I would be able to access this service via js from a web page that is served from my site.</p>

<p>1) User installs client software that installs itself as a service and waits for authenticated requests on 127.0.0.1:8080</p>

<p>2) When the user hits my home page js on the page makes an xhtml request to 127.0.0.1:8080 and asks for the status</p>

<p>3) The home page then makes another js request back to my web server sending the status that it received.</p>

<p>This would allow my users to upload/download and edit files on a USB attached device in real-time from a browser.  Polling could be the fallback method which is close to what we do today. </p>

<p>Has anyone done this and what potential pitfalls are there? Will this even work?</p>

I can't see any potential pitfalls. I do have a couple of points however.
1/ You probably want to make sure your service only accepts incoming connection from the local machine (127.0.0.1).  Otherwise, anyone could look at your JavaScript and figure out that it's talking to [your-ip]:8080. They could then try that themselves from a remote site (security hole).
2/ I wouldn't use port 8080 as it's commonly used for other things (alternate HTTP servers, etc.). Make it configurable and choose a nice high random-type value.
3/ I'm not sure what you're trying to do with point 3 but I
think
you're trying to send the status back to the user. In which case, why wouldn't the JavaScript on your home page just get the status in a single session and output/update the HTML to be presented to the user?  Your "another js request back to my web server" doesn't make sense to me.