Yes, this is possible as the reference is automatically filled on the other side if the reference type is both. If you set the reference between A and B, in memory A gets a reference to B and B gets a reference to A.
Important to note is that both object A and B will be changed in cache in this case. Every change made in a change activity on a object in microflow is stored in cache and setting both references causes an object retrieval of the other object from cache (in this case B) and then setting the reference value (to A in this case) for this object.
So, if you, after setting the both reference, change an attribute, say "Name" of object B and subsequently retrieve B from association through A you'll get the modified value of the "Name" attribute for this newly retrieved object.
No this isn't possible, and this could even cause a bigger problem. If you don't keep this in mind.
Say you retrieve both objects at the begin of the microflow(or receive them as input parameters) and then you set the reference from A to B and commit. If you look in object B you won't see the new value for the changed association. This is because object B already exists in that microflow and you don't want it to change because you have changed object A.
Objects you retrieve at the start of a microflow will keep their original value unless you explicitly change the attributes or associations. If you change the association like in your example any related attribute won't change automatically, the object (B in your example) will keep the old value untill the end of the microflow OR untill you retrieve the object again.
This is the desired behaviour. See this example what would happen if associations would update automatically:
Both object A and B are input parameters. You change object A and set the association to object B. (Object B automatically refreshes and now has the association to object A) Now you change some other attributes in object B and then commit object B. (The association will be committed as well). You execute some business rules and see that Object A can not set an association to object B, you rollback the changes in object A. BUT because the association between the two objects has been committed with object B the changes can't be rolled back.
If object B wouldn't refresh automatically this case would work fine. I can think of a few more cases why this is the desired behaviour but this one is the easiest to explane.