If you're trying to use ActiveResource in a Rails app as a plug-and-play replacement to ActiveRecord, it really doesn't work like that. One way you can make your life a lot easier is to build a metaprogramming/reflection process into ActiveResource based on the process inside ActiveRecord.
As it turns out, this is easy to implement. ActiveRecord loads its database's schema on class definition using a SHOW FIELDS command. If you have control over the application ActiveResource is hitting, you can add a schema URL pretty effortlessly. Then, on the actual ActiveResource app, you just put an alias_method_chain on inherited in ActiveResource::Base. Add in an autoload method; have that method do the work of an attr_accessor, except don't actually use attr_accessor, because you need to put the attribute in the @attributes hash for it to be any use.
In some ways, this is like using an WSDL file, and it might give you the creepy-crawlies for that reason. In fact, however, it's a lot more elegant. It's dynamically generated, and its syntax is very clean, so you have none of the maintainence and coupling issues WSDL gives you.
It's also much more economical than attaching attr_accessors all over the place with class << self every time you need to use a form handler, and better from a performance standpoint than Rails' default behavior. If you're using ActiveResource stock, unmodified, out the box, you get a method_missing approach to @attributes which ActiveRecord abandoned a few versions ago in favor of more performant code-generation techniques, i.e., explicitly defining and attaching new methods, rather than passing all the work to method_missing. In a sense, method_missing is a lot like the iPhone when it was first released: amazingly cool, but way too expensive. (Fortunately, method_missing was never saddled with an AT&T service contract.)
If you've been following along, or attempting to actually code this from my description, you've probably noticed the big flaw: it doesn't account for association classes. That's pretty easy to fix. Use has_many (and its big family) in your ActiveResource models, and add the has_many family of class methods to ActiveResource::Base. The best way to implement it is to have it do exactly the same thing your autoload code already does in generating its accessor methods. Essentially, the only difference between has_many :widgets and attr_accessor :widgets should be that has_many also updates @attributes. The smart thing is to factor that out, so you can have both the autoloading code and the has_many family hit a class method with a name like add_attribute.
As you might guess, I have some code to show here, but I can't show it at the moment, partly due to corporate politics (LAME) and partly due to not having actually finished it yet. I literally just thought of the has_many part as I was writing this. We've got a lot of this working at my current project, however, and we should have it running in production very very soon.