I think there are two related but distinct issues here: the URLs exposed and the controller methods they are routed to. Since either of these could be changed independently, I'll address them separately. Also, please note that I will be speaking a bit loosely, and strictly about REST as implemented in the context of Rails.
In terms of the external URLs, I think it helps to distinguish between the URLs that make up the API of the system (:GET users/1
, :PUT users/1
, etc) and the URLs that are just there as a convenience to humans using a web browser (users/new
, users/5/edit
, etc). The API is all about fetching resources or interacting with them in some way - these are the URLs that another computer is going to use when interacting with your system. These URLs are typically just the address of the resource you want to interact with, and then you use the HTTP method and the parameters to indicate what it is you want to do (GET = show me this resource, PUT = change this resource, etc). The convenience URLs are there to display a form to make it easier for a human to use the API. You could edit a user by using curl to manually type out all the parameters you wanted to change and make a POST to users/1, but as a human it's a lot easier if you can just use a form.
To look at your examples above, then, :GET users/create
might make sense (and is pretty similar to :GET users/new
which is the default), but :POST users/create
would roughly translate to "make a new one of users/create", which doesn't quite make sense.
As far as the controller methods go, "new" and "create" are performing fundamentally different tasks, as should hopefully be clear from the previous paragraphs. One of them is displaying a form, and the other is creating a new resource. You could overload the same method to do this, of course, but without a compelling reason to do so, creating two small independent methods to handle two small independent tasks is probably a more natural approach.