I don't think this is as useful as you may want.
The streaming API will not work with a standard XHR call, since there's no specified way to flush the request buffer. I believe browsers just hold the response data in memory until the request closes, which is not supposed to happen in a streaming request. I also suspect that such a client will cause a lot of connection churn due to page refreshes, something we want clients to limit. In general, a HTML page is not a good candidate for a streaming API client.
For the REST API, we offer JSONP for public read operations. But for write operations, OAuth 1.0a is not suitable for HTML clients, since there is no way to keep a consumer secret hidden, meaning anyone could spoof your application. This is also a practice we want to limit.
In general, it sounds like it would be an interesting experiment, but the reality is that such a client would not be useful as a production application.