Quick takeaways:
1) You can break almost all spambots by requiring them to evaluate CSS or Javascript to avoid a tripwire. For example, I have a field on all my (publicly accessible) forms labeled "comment" and hidden via CSS. A before_filter bounces anybody who puts anything in it. Simple, took 5 minutes to implement, reduces spam registrations to essentially zero.
2) It was easiest for me to create virtual user registrations in a private namespace (trial users provide an email address, virtual users are given an unguessable email address on my domain that does not actually correspond to a mailbox) and assign them a particular limited role, which let me reuse almost all of the code for "real" trial users. This lets you upgrade people out of virtual userhood trivially -- grab the virtual user, write over two fields, save to DB. Done.
If you do it like this, and give the virtual users sensible defaults, you minimize the amount of almost-duplicated-but-not-quite code that you have to include in views. That will save you on a lot of bugs and aggravation. (Reproducing bugs for particular well-used "virtual" users is a pain in the keister.)