My understanding of Browser ID is that it's a way to provide an email address to a site operator that doesn't need to be confirmed. It's a single-step subscribe/account creation, rather than an authentication per se.
In the mockmyid case, you are saying "I own the address xyz@mockmyid.com". But the MockMyID server will happily let anyone make such an assertion, so you get a simple kind of mock identity.
Of course, you shouldn't use that as your identity on any sites that you care about. Mail to anything@mockmyid.com doesn't go anywhere, and there's nothing to prevent other people from using the same @mockmyid.com address. But it's a neat example of the sort of thing that is possible.
That's mostly right. The BrowserID protocol gives you a way to say to a site "Hi, I'm someone@mockmyid.com, and here's the proof." That proof is, in part, a certificate that has been cryptographically signed by the user's email provider.
Now, to verify that, instead of asking the user for a password, or emailing them a confirmation link, you just have to check the cryptographic signature on the certificate. So in this case, you'd go request mockmyid.com's public key at https://mockmyid.com/.well-known/browserid, verify the signature, and if it all checks out, you can let the user into your site!
As for being a "single-step subscribe/account creation", you're spot on. Since there aren't any per-site passwords anymore, there's no difference in the flow for a returning user and a brand new user, since they both say "Hi, I'm name@example.com, and here's the proof." If that user exists in your database, great! log em' in. If not? Yay! You have a new user. Ask them for any additional information you might need.