Is there any specific usability reason why the standard order of form elements for entering an address is this order:
Wouldn't it make more sense to go the reverse way? Thereby going from broad to narrow, instead of narrow to broad? From a technical perspective, this would make auto completion better (search results will narrow down). Additionally, from a human perspective, this seems more logical. That is:
Do you think I could do this without confusing users, given that this diverts from the standards?
I think you can get away with it, but don't underestimate the potential that deviating from accepted conventions has for confusing users.
With regard to autocompletion, I sometimes see the country being required first (as in your example) in order to power state/province dropdowns, but the rest of the fields are in order, i.e., address still comes before city. Assuming you don't have any special requirements, I wouldn't recommend completely flipping the conventional order of these address fields.
While the order you have mentioned is typical for a specific group of countries, it may be totally different in other ones. In other words, whenever you refer to some specific order, it comes from a popular convention in a specific country (or group of countries).
Going against standards (which are parallel to these popular conventions and thus also to user preference) will always make users confused. Thus, if there is no need to do so, you should not change this order for just one system. Of course, if the change would mean simplification of the form, it could be considered, but simply rearranging the fields won't do so. In this case, you will end up only with the negative effect (confusion) and without the positive one (simplification). The balance for the user experience is negative.
For further reference, you can read more about specific address fields conventions in various countries e.g. here: http://www.uxmatters.com/mt/archives/2008/06/international-address-fields-in-web-forms.php and here: http://bitboost.com/ref/international-address-formats.html (a list of international address formats).
(I work at SmartyStreets, where we research and experiment with address-related UX.)
Country should go first. Then you can customize the appearance of the form, if you wish, for certain countries, so that users will feel more comfortable entering their address.
However, going entirely backward from the broadest region type to most narrow isn't the best strategy because it will throw users off. I've written about this here. (Further, there has been some mention of using postal code to auto-fill city/state: you don't want to rely on the postal/ZIP code to do that, because they change frequently, and in the US at least, a ZIP code often maps to multiple cities/states, whereas the city/state hardly ever change.)
What you should do is put the address field next. Ideally, you'll combine as many address fields into just one so users can enter their address in a way natural to them. (But don't forget to verify their input or you might be hurting later.) Even more ideally, start with the street address field and then auto-complete the rest from there. This is most natural to the users.
For example, here's a free address auto-complete service which fills out city, state, and then verifies to get the ZIP code after the user has typed only (part of) their street address. Here's some more info about address auto-complete. It also works on freeform address fields.
Our eye-tracking tests of checkouts confirmed that users have no trouble with the unconventional address sequence of having the ZIP code field first.
Presenting “City” and “State” beneath the “ZIP code” field will initially break the traditional address field sequence, at least for US users where the conventional printed address information sequence is “Name, Address Line(s), City, State, ZIP.” However, the downside of an unconventional field sequence proved negligible during testing (of US address forms), compared to the gains in completion speed, user delight, and reduced typos.
(emphasis in original)