This is not a good idea. But that's not a problem of SRP.
SRP is a Password-Authenticated Key Exchange protocol by which two parties establish a shared secret with mutual authentication through another shared secret. The beauty of the thing is that the initial shared secret may be weak (i.e. a password that human users can remember), and yet the new shared secret is not susceptible to offline dictionary attacks.
A dictionary attack is a brute force attack on a human-compatible secret. The attacker tries "potential passwords" until the right one is found. An offline dictionary attack is a dictionary attack where the attacker has obtained enough information to test passwords at home, without interacting any further with the target systems; e.g., if the attacker has a hash of the password, then he can try passwords by hashing them and comparing with the known hash value. Offline dictionary attacks are powerful because nothing prevents the attacker from throwing more power at the task, through dedicated hardware (GPU, FPGA, ASIC...), rented systems (commercial clouds), or even "borrowed power" (idle machines in a University network, botnets...).
A contrario, if an offline dictionary attack is not possible, then the attacker must use an online dictionary attack, and then things begin to look better because the honest systems can limit the rate at which they respond, or even stop responding after too many failure. This is the behaviour of a smart card with a PIN: after a few wrong PIN, it just locks itself.
The whole point of PAKE is to avoid offline dictionary attacks. Attackers MUST talk with either the genuine client or the genuine server whenever they want to test a potential password. This has a few consequences for your case:
PAKE protocols, in particular SRP, naturally provide forward secrecy (also known as PFS). Forward secrecy is about preserving confidentiality of past communications even against attackers who later on manage to steal long-term stored secret values of either or both parties. In the case of TLS-SRP, the only long-term stored secret value is the shared password.
Suppose that there is a procedure P by which an attacker, after having recorded (passively) a connection, and having later on stolen the shared secret (the password x), can unravel the contents of the connection. Forward secrecy is achieved if such a procedure P does not exist. However, if P exists, then the attacker can turn it into an offline dictionary attack: the attacker just has to "guess" the password x, and try procedure P using that guessed value of x. If it works, then the guessed password x was correct.
In other words, if a PAKE protocol does not provide forward secrecy, then, mechanically, it does not provide protection against offline dictionary attacks either, so it is not a "true" PAKE protocol. Conversely, good PAKE protocols like SRP necessarily provide forward secrecy.
The explanation above naturally extends to the case of a public password. A public password is just a password for which dictionary attacks are really efficient (attackers get it right on first try...). Thus, you still get forward secrecy even if the password is known to everybody.
However, all of this relies on important details. The "forward secrecy" property is about an attacker who passively recorded a connection, and tries to decrypt it afterwards. In particular, it says nothing about active attackers.
If the password is known to everybody, then the attacker may pose as a fake server, or a fake client, or both at the same time; notably, the attacker may run a Man-in-the-Middle attack. Such an active attacker can then intercept connections and see all the data as it flows. Since the MitM still forwards data both ways, the genuine clients and servers will be none the wiser.
This explains why I used emphasis on the "mutual" word at the start of this answer. When you say:
we explicitly do not want authentication, we just need the encrypted data for each session to be protected
then this is a kind of contradiction in terms. What you really mean is either of the following:
you do not want client authentication (but the client must still have some guarantee that it talks to the right server);
your usage context is such that attackers cannot be active.
Passive-only attacker contexts are, in fact, extremely rare, and most people who just assume that attackers can not alter data in transit are merely delusional, and primed for a rude awakening at some point. So we are back to point 1: the client should still be able to know whether it talks to the right server. In SRP, the shared password is the basis for mutual authentication. By making it public, you remove authentication in both directions, and that's too much removal.
There cannot be any notion of authentication if everything is known to everybody. But SRP is based on the idea that the only secret is the shared password. So you cannot get server authentication if that only secret is not, in fact, secret.
If you want an "unauthenticated" communication (server does not know who the client is; but the client still knows who the server is), then SRP is not the way to go. Rather, you will have to use the "normal" SSL/TLS in which the server has a public/private key pair, and the client knows the public key, or learns it dynamically through the server's certificate (the latter implies certificate validation, which is what Web browsers do, but maybe you would have preferred to avoid certificates altogether).
Summary: yes, SRP provides forward secrecy, even if the password is public. But no, this is not a good idea, because forward secrecy is not the only thing you really want; you also need normal secrecy, and that one cannot be maintained against active attackers if you use SRP with a public password.
