The main problem with tunnelling IP into HTTP GET requests is that HTTP is a client-driven protocol: the client always talks first, and the server cannot send anything to the client save as a response to a request. In pure TCP/IP, both parties must be able to talk at any time they wish.
The two main methods to solve this issue are:
Polling. The client sends requests at very regular intervals, say at least once or twice per second. The server responds with either a chunk of data, or a message that says "nothing to send back at that point".
Stalling. The client sends a request, but the server does not respond until it has indeed some data to send to the client, or some given amount of time has elapsed. Either way, when it has received a response, the client immediately sends a new request, for the next data chunk.
The stalling mechanism is more discreet, and less resource intensive; however, it is more complex to setup and operate, notably because the client then needs two channels, for sending and for receiving encapsulated packets. The terminal-over-Web Anyterm products uses the stalling mechanism; however, it does it with XmlHttpRequest, which sends POST requests, not GET. See also the BOSH protocol, that uses the same principle, explained in more details in section 4.
The concept can be applied to HTTP GET requests; you would probably have to encode outgoing data in the target path, or as a custom header, because HTTP GET requests are not supposed to have non-empty bodies (the HTTP standard allows for it, but it is not supposed to happen in practice, and I believe that it would make the firewall very suspicious).
I don't know of any existing tool, but this is a nice programming exercise.
Of course, getting past the firewall configuration is only part of the subject. I presume that whoever puts such heavy constraints on Web requests will also install some monitoring devices to get warned about unusual network activity, and any tunnelling should trigger such a system.