Given what you've said, perhaps if you restart the process which contains the web browser control (or the process which is the web browser control), after you change the default printer? That's the kind of thing I see happening here, for example.
I suppose it would be possible to fork off a background process that does the actual printing, but I'm really hoping for a simpler solution.
Forking was my first thought towards a probably-simplest solution.
Some other alternatives are as follows.
1). IE, which the webbrowser control is wrapping, exposes APIs via ActiveX. One of its/those APIs might let you specify the destination printer.
2). Some executables (I don't know about IE) have printto entries in the registry. For example, Acrobat Reader has an entry whose value is as follows:
""C:\Program Files\Adobe\Reader 9.0\Reader\AcroRd32.exe"" /t "%1" "%2" "%3" "%4"
That's used for specifying the syntax of the command-line which you can use to print and specify a (non-default) printer. You can also Google for printto, see e.g. PrintTo command in the ShellExecute.
3). I have implemented an HTML control for .NET of my own, which doesn't depend on IE. You say that your HTML (and CSS I presume) are simple, so perhaps I can render it, either out of the box or with only a little extra development effort. I don't support printing, but printing is quite easy for a user control to implement. Getting me to implement that for you would cost you several hundred but, who knows, maybe it's worth it to you. It would be quite a light-weight solution, and perhaps well supported. You could email me if you want to discuss that further.
4). You might also find other controls, similar to mine, more or less famous/expensive; or other applications, e.g. OpenOffice etc etc.
5). You could consider converting the HTML (somehow) to another format (e.g. PDF) for which you have an application which gives you better support for printing.