Ask HN: Is my unorthodox approach to server security a bad idea?

I've heard people say again and again that you shouldn't implement your own security algorithm, and I'd like to ask HN if I'm breaking this rule.

I'm creating a traditional client-server application with a twist: I want to encrypt all data on the client so that even an attacker who gains complete control over my server will be unable to access the users' data. That is, I want end-to-end encryption for my client-server application.

The client encrypts the user's data with a cryptographic key derived from the user's password, so it's important that the server not be able to figure out the password because that would allow the server to decrypt the user's data. The client therefore uses Secure Remote Password protocol to avoid sending the password to the server. So far so good.

Now here's where my design gets a little unorthodox. The problem is that users in general are very bad at creating passwords - usually picking a password from the top 10,000 passwords list - which would make it pretty easy for an attacker who has access to the server to decrypt the user's data. Therefore I plan to generate a random set of characters and append them to the User ID field, so the user would need to log in with something like these credentials:

  User ID: John-CPE4E38J
  Password: snoopy

But before processing these credentials the login code moves the random characters to the password so the underlying SRP authentication library sees this:

  User ID: John
  Password: snoopy-CPE4E38J

In addition, the client offers to remember the User ID (ie. John-CPE4E38J) so that most of the time the user only has to remember their password.

What do you think of this approach? Am I breaking the do-not-implement-your-own-security-algorithm rule? Or is this a good way to strengthen the security of my application?

[1] http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol