No, there is no documentation from Microsoft guaranteeing the behavior, therefore it is not guaranteed.
Additionally, assuming that the Simple Talk article is correct, and that the concatenation physical operator always processes inputs in the order shown in the plan (very likely to be true), then without a guarantee that SQL will always generate plans that keep the same the order of between the query and the query plan, you're only slightly better off.
We can investigate this further though. If the query optimizer was able to re-order the concatenation operator input, then there should exist rows in the undocumentated DMV, sys.dm_exec_query_transformation_stats corresponding to that optimization.
SELECT * FROM sys.dm_exec_query_transformation_stats
WHERE name LIKE '%CON%' OR name LIKE '%UNIA%'
On Sql 2012 Enterprise Edition, this produces 24 rows. Ignoring the false matches for transformations related to constants, there is one transformation related to the CONCATENATION Physical Operator UNIAtoCON (Union All to Concatenation). So, at the physical operator level, it appears that once a concatenation operator is selected, it will be processed in the order of the logical Union ALL operator it was derived from.
But about the Logical Union All operator (UNIA)? There is a UNIAReorderInputs transformation, which sounds like it will switch the order of the inputs. There also appear to be two physical operators that can be used to implement a logical Union All, UNIAtoCON and UNIAtoMERGE (Union All to Merge Join). Therefore it appears that the query optimizer can reorder the inputs for a UNION ALL, however, it doesn't appear to be a common transformation (zero uses of UNIAReorderInputs on the Sql Servers I have readily accessible.) Also we don't know the circumstances that would make the optimizer use UNIAReorderInputs; it may only be applicable to a Union All implemented with a MERGE JOIN.
Regarding your second question, "Is there a way to have the engine process more than one input at a time?" The concatenation physical operator can exist within a parallel section of a plan. With some difficulty, I was able to produce a plan with parallel concatenations using the following query:
SELECT userid, regdate FROM ( --Users table is around 3mil rows
SELECT userid, RegDate FROM users WHERE userid > 1000000
SELECT userid, RegDate FROM users WHERE userid < 1000000
SELECT userid, RegDate FROM users WHERE userid < 2000000
) d ORDER BY RegDate OPTION (RECOMPILE)
So, in the strictest sense, the physical concatenation operator does seem to always process inputs in a consistent fashion (top one first, bottom second), however, the optimizer could switch the order of the inputs before choosing the physical operator, or use a MERGE join instead of a concatentation.
This is all speculation.