State changes, such as moving a portlet to the maximized mode must be done during the even processing phase, and unfortunately, when a portlet first renders, the even processing phase is bypassed.
With WebSphere, we have special pages called screens, where a screen occupies the entire, renderable, window. These are used for registering for the portal, logging in, and self-care activities. A WebSphere Portal Screen might be applicable for this situation if a) you are using WebSphere Portal, and b) if you don't expect this app to be deployed as a normal portlet.
Another option might be to make it the only portlet on the page, and then lock the page so the use cannot add any new content.
Of course, I don't really like any of these ideas in a portlal. It makes you question the reason as to why you are using a portal in the first place. Working with the portal means a bit of a mind shift - you have to think portal, and rid yourself of the JSF, Struts and Servlet/JSP mentality.
What is the compelling reason for keeping the portlet maximized?