Both DataMapper and ActiveRecord support 'custom attributes' of the type described (custom getters and setters is more accurate) -- it's all Ruby, after all. But that misses the point: conceptual coherence, declarative coding, responsibility decomposition, and more.
The ActiveRecord team recognizes the value of the Property API: in ActiveRecord 3.1 the AR::Base.serialize method is enhanced to support custom serialization, one portion of the Property API: http://edgerails.info/articles/what-s-new-in-edge-rails/2011/03/09/custom-activerecord-attribute-serialization/index.html. However, the Property API provides far more than custom serialization.
To understand it (coming from an ActiveRecord background), try to imagine a unified API covering the functionality currently fragmented between ActiveRecord's inferred attributes (ie., every DB column is a converted into a primitively-typed attribute), AR::Base.composed_of and AR::Base.serialize, then add model annotations and conceptual coherence and you're getting close.
When using a schema-less datastore (cassandra, riak, redis, mongo, couchdb, etc) application code defines the 'schema', rather than the other way around. As such, several of the non-relational projects/bindings/adapters use something like the DataMapper Property API to declare model attributes.
* ToyStore: https://github.com/newtoy/toystore/blob/master/examples/models.rb
* SuperModel: https://github.com/maccman/supermodel/blob/master/README#L59
* Mongoid: http://mongoid.org/docs/documents/fields.html
In other words, the whole premise of reflecting upon a defined DB schema to infer attributes is meaningless in a schema-free world; something like the DM Property API is a *necessity*. But none of the referenced projects offer the full power of the DM Property API.