Yes, all that could be possible, but it is not implemented yet.
We can naturally have multiple thread creating and submitting command lists, lists can be submitted multiple times (though the application need to pay attention they are not still in execution).
However, only one command lists at time is executed by the system and the order of submission is preserved by a runtime serialization. Moreover methods on a specific cmd-list object are not free-threaded, nor are cmd-allocators, so the application must take care of cmd-lists and cmd-allocators synchronization. On the other side the command queues are free-threaded, but we can currently have only one graphics queue (copy and compute queue should not have such restriction).
I am not aware about details (someone here could probably give you a better answer ( : ), but looks like that the context switches caused by async command buffer execution (that happen actually on kernel mode) could cause some sort of issues.
I would be not surprised though if in a future update the execution of command will happen completely in user mode, with a true async command list model.
Finally, I am not aware of a single GPU having more then one graphics engine per node, so I do not know how well would suit having multiple graphics command queues.