A way you could do it is to have the servlet send back a redirect header
(or a brief HTML page containg a 'refresh' type redirect, if you want)
that sends the client browser back to the input form, but with the
username (or whatever else) provided as GET style parameters in the URL.
Then the actual input form page can be using Javascript which reads the
GET parameters in the URL and uses them to populate the form.
This way you can avoid having to return the HTML content from the
servlet itself.

More details here:
http://javascript.about.com/library/blqs.htm

To give a brief illustration of what I mean, suppose your create user
page is at this URL:

http://www.someSiteImade.com/createUser.html

... this page contains an HTML form which POSTs or GETs the new user
info to the serlvet at:

http://www.someSiteImade.com/checkUser

This serlvet then in your situation presumably rejects the username as
already taken (or similar) and wants to return them to the create user
page. So it sends a redirect header which makes the client browser go to
this exact URL:

http://www.someSiteImade.com/createUser.html?username=Freddy

(where 'Freddy' is the username that already exists!)
Now, the createUser.html page has some clever javascript in it which
checks for the username parameter being provided as part of the URL. If
it was provided, the Javascript populates whatever field in the form
with 'Freddy' (or whatever was sent). Hey presto digitato.

Or, another way to do it - but the way you seem to want to avoid - is to
have the create user page at the server side, as a servlet that spews
out a template. If the servlet deems appropriate, it could insert the
username/whatever into the template it was returning.