Actually, this might not work. With the above approach, the client could get load balanced to a different server than the one that generated the session. To avoid this scenario, you'd need to parse the persistence token in the response and then persist on it in subsequent requests.
Does the application include the session ID in a redirect or other HTTP response header? If so, you could parse the session ID relatively easily. Else, you'd need to look through the response content. For the latter approach, there's a codeshare example:
Persist client on response content with stream
http://devcentral.f5.com/wiki/default.aspx/iRules/Persist_client_on_response_content_with_stream
If you can clarify whether this is a problem and if so where the session ID can be found when it's initially created, we can provide you with more suggestions.
Aaron