Prim's Algorithm - Building the Priority Queue
Assuming your PQ is backed by a heap (as you refer to it later). Since the only invariant in a heap is that the parent must be $&lt;$ the children (heap property) you can see there can be no ordering between children of a single parent. A priority queue will always return you the minimal element regardless of order, just think about how $\min$ works: $\min\{1,2,3\}=\min\{2,3,1\}=\min\{3,2,1\}$.
Because a heap is represented in a continous array, you'll have $[b, c]$ after removing $a$ which means that $c$ will always be the left child. Look at the heap image on Wikipedia and notice it's leaning left.
Yes, that's the order they'll be in a usual heap, because all their weights are $\infty$. But any other structure (regardless of insertion order) would be acceptable as long as $a$ is the root, because it wouldn't hurt the heap property.



  parent-child relationships [in PQ's heap] do not correspond to the
  parent-child relationships in the original graph


That is absolutely correct. Just because your PQ is backed by a heap which encodes a tree you can't assume that the graph structure will have anything to do with the heap tree's structure. Just think about a non-tree graph with cycles and multiple edges between vertices: how would that be reflected in the heap's tree? There isn't even a correspondence with the partial MST.

Another argument: the whole structure correspondence breaks big time as soon as you modify just one key in the heap and sift it to it's place. For example:

     a(0)                            a(0)
   b(∞) c(∞)   --- d.key = 1 --&gt;   d(1) c(∞)
 d(∞)                             b(∞)


even before modifying the key $d$ was the child of $b$ which wasn't true in the graph and is not even reachable. The same is true after modification for the reverse.



The best is to think of a PQ as:

interface PriorityQueue {
    add(node, cost)
    update(node, cost)
    (node, cost) popMin()
}


the fact that it's implemented as a heap shouldn't be of a concern, just assume that the PQ does add and update in $\mathcal{O}(n\log{n})$ and popMin in $\mathcal{O}(1)$ to get quasilinear runtime of Prim's algorithm. Even when you implement it you should separate the algorithm from the PQ implementation.