Your mileage may vary, and I don't guarantee I'm reading your code right, but:
1) You will find it useful to be able to coerce A/B test values, particularly in testing and sometimes (for CS purposes) on the live site.
2) I do not see a convenient method of having Ms. Smith get the same website at home and at her workplace. That may or may not be a problem for you.
3) You may find "control" and "experiment" to be limiting once you start doing this frequently -- they aren't nearly as self-documenting six months down the line when you're staring at your web page wondering "What possessed me to make this button teal?!"
4) I'm pretty sure you have a race condition for creation of new tests. (This has bitten A/Bingo a few times.)
A/Bingo has a notion of "identity" (a string which is unique among users of an application). If you don't have one, you get one assigned randomly. Your identity gets associated with your account as early as possible, and if you sign in on another computer, I overwrite that computer's identity with yours. (Merging would be cleaner, but this works in practice for my site.)
The way A/Bingo picks alternatives guarantees that someone with a particular identity will always see the same alternative for a particular test. See the source code for details.
Since identity management is abstracted by the A/B testing framework, you can make it as simple or complex as you want, and it hooks into user management with on the order of ~5 lines of code.
Would you mind pointing out implementation choices, that will come back biting us down the road? :)