Mark, I think the combination of your expertise and "fresh eyes" can yield great usability/understandably benefits. My recommendation would be to treat the fact that bad guys can't break-in as "the air"...it's all around us, but we don't really notice it. Sum it up as "the power of cryptography" and assure the user that the system has been designed from the bottom-up so bad guys can't harm you. Then throw in the fact that in a decentralized system like this, there is more responsibility on the part of the user. But everywhere else, I think it would be wise to simplify interactions and terminology, ignoring underlying details unless there's a clear need for the user to understand something. So the fact that something is getting encrypted or decrypted isn't important for the user to know, for instance, because that's just part of the bottoms-up secure design.
Also, I see that there might be a "SQRL client lite" that might be an interesting place to start. The client would not have any identity creation / management functionality. When you first opened it, it would scan an identity. After that, it would scan login codes and accept master passwords and quick passwords to logon to web sites. No other functionality. If you scanned another identity (or the same identity a second time), it would simply confirm that you wanted to replace the single identity (because we limit this client to one identity). Settings > About would be the only other thing needed. The idea is that this client would be super simple on the face of it (but of course the full crypto implementation under the covers). The identity creation function would, of course, have to be be done not on the lite client, but on the user's "main SQRL client".
So if the UI for the lite version was defined, it could also make the full implementation clients more usable since all that other "stuff" could be buried deep. I was thinking that some of that stuff should require entering the master password, even though it's not required technically. There's LOTS of stuff that should NOT be easy to access! In fact most of the stuff on that diagram posted earlier should not be easy to access. The identity creation should certainly be easy to access on the full client, at least if the state of the machine is that it has zero identities. Once it has one identity, it should be buried deeper. Some activities, like changing master password and re-keying need to include a way to keep the user out of hot water because there are bunches of pitfalls if they have multiple clients. So support for the whole "synchronize clients" thing will probably consume quite a bit of "strings.xml".
If any of that doesn't make sense, I'm sure it will once you start playing with it yourself. Cool you're here.
