I did something which is sort of similar for my site.
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.)
I do something similar to your (1) but as I didn't want people with text browsers or screen readers to have problems I have a field labelled to look tasty for spambots and pre-filled with "don't alter this text" or similar and check that the text is unchanged. It seems very effective.
We recently struggled with this on the design of the front page of an application. A similar issue we ran into is scaring people away with login/password boxes on the front page.
What does everyone think, is it better to have the login/password boxes visible immediately to save the user a click, or do what digg and twitter do to avoid scaring people about a sign-up form in the not so distant future and hide it behind some AJAX?
I think its better to do whatever the A/B test says works better for your particular users.
I burned two hours a week ago trying to test that but my CSS and lightbox implementation did not play well with each other and I eventually scrapped it. I'll take another stab at it in November -- no killing the magic pumpkin before Halloween.
I have compelling evidence that using a lightbox to "pre-sell" the form/download increases conversion rates, at least among my users. Try clicking on the giant image in the middle of my home page -- it works beautifully.
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.)