First, since browsers don't support SRP, we are necessarily talking about a custom local application.
For security, it is important that the local application code is "safe". We have to assume that the user did not initially have the application, then obtained it and installed it on his computer. This must occur before the SRP enrollment. And yet users must have a way to make sure that the application code they install is the genuine, non-hostile one. Maybe they got it from a CDROM/DVD; maybe they downloaded it through a "secure channel"; maybe the binary is signed. The attacker would like to insert his own code in that application, so there MUST be some mechanism to defeat the attacker at that point.
Assuming that the application code is safe, then that application code may embed a copy of a public key owned by your server; e.g. a copy of the server's certificate. That certificate may be self-signed, or issued by a custom CA, or whatever: since the application knows a priori the server's public key, it can establish a secure tunnel with the server through SSL, and without involving an external CA: the application just checks that the certificate used by the server is bit-to-bit identical to the embedded one. At that point, you can transmit any user-chosen password without fear of hostile eavesdropping. Arguably, you could also keep on using that SSL and not do any SRP at all.
The "embedded public key" model is simple and will work -- that is, if it does not work, then this means that you have a bigger security issue that you cannot solve with any amount of SRP.
As a side note, this example shows that SRP, though a massively spiffy algorithm, is not necessarily useful in contexts where custom, server-specific application code is installed on the client side. The real goodness of SRP occurs when the client code is generic, e.g. is a Web browser which does not include any site-specific code. But we are not there yet; browsers don't know how to do SRP (for the time being...).