Looks like it:
$ host vekslers.org
vekslers.org has address 216.239.32.21
$ curl -D- VEKSLERS.ORG
HTTP/1.1 302 Found
Location: http://www.vekslers.org/
Date: Fri, 01 Oct 2010 14:27:22 GMT
Content-Type: text/html; charset=UTF-8
Server: ghs
Content-Length: 221
216.239.32.21 is owned by google, so it looks like they are emitting the redirect to www.vekslers.org.
When they say they do not handle "naked" domains I think they mean you cannot serve your site from a naked domain. Instead you have to let them redirect the naked address to the non-naked one as they are doing above.
Option 1 will not work with S3-hosted web sites because what S3 sees in the Host: header of the incoming HTTP request must match exactly the name of the bucket, and setting a duplicate A record does will not solve your problem.
Option 2 will not work for the same reason -- the request will never arrive at the bucket containing the redirect rules except for requests directed toward the actual name of the bucket. The answer you linked to is nothing more than the "hard way" of doing Option 6, and requires one bucket per hostname.
Option 3 is not useful because PTR records don't cause browser redirects. Usually used for reverse-DNS, A PTR record has no application in this context.
Option 4 Go Daddy has options called "Domain Forwarding" and "Subdomain Forwarding" but this means you have to have your DNS hosted by Go Daddy, not just have your domain registered there (those are two different things that often, but not necessarily, go together). If this is what you have now, you can "forward" the "www" subdomain (www.example.com) to the apex (example.com) which Go Daddy accomplishes by creating either A or CNAME records for www.example.com which point to their own web servers, which generate HTTP 301 or 302 redirects to http://example.com. If your DNS is hosted with Go Daddy, and not on Route 53, then this is probably the simplest option, but if your DNS is not hosted with Go Daddy, this option is not available. Since you are using the apex of your domain as a web site in S3, I'm assuming your DNS is hosted with Route 53, which means this won't work.
Option 5 seems like a bad idea, introducing an unnecessary third party into the equation, but more importantly, it solves the wrong problem. They don't redirect www.example.com to example.com, they redirect example.com to www.example.com.
Option 6 is a good choice, with the drawbacks that you mentioned, regarding the limited number of buckets available to each AWS account.
If you have that many different domains, than another option would be to allocate an Elastic IP Address in EC2 (so that you have a static endpoint IP address that won't change), then spin up a Micro instance bound to that IP address and install HAProxy on it. HAProxy is actually designed to front-end actual web servers and load balance traffic to them from the outside world, but it also has the capability of generating redirects. Configuration is not terribly complicated, and HAProxy is very efficient with CPU, so I would expect you'd get a lot of work out of a Micro but could always scale it up to a larger instance if traffic made that necessary.
You'd configure a front-end listener on port 80:
frontend main
bind *:80
And then for each domain create an access control list (acl) to watch for requests containing that hostname in the "Host" http header...
acl www.example.com hdr(host) -i www.example.com
...then configure a redirect to generate a 301 to the desired hostname.
redirect prefix http://example.com if www.example.com
In DNS, you'd configure www.example.com with an A record pointing to this Micro instance's public Elastic IP address.
With this configuration, the path is preserved, so a request that is sent to any path, sush as http://www.example.com/foo/bar will be met with an HTTP 301 redirect to the exact same path on the other domain, such as http://example.com/foo/bar.
You can do similar things with an actual web server running on a machine, such as Nginx or Apache, but HAProxy is a very heavy-duty-yet-light-weight tool that seems quite appropriate for such a task, and generating redirects like this this is one of the things that I use it for in my operations.
Best Answer
I've been having the same issue almost 3 years later and it seems pretty clear that this is not possible through DNS/Google alone. You have to host somewhere separately with an SSL cert installed for the naked domain otherwise it won't work, so unfortunately the answer is: No
At least Google have updated their article to explicitly state that the redirect doesn't support https (some older posts I've found imply that this was not previously specified in the article.