First, with respect to your second question regarding applicability to GPU-generated data, yes - you need some terrain height information available to the CPU, as all of these occlusion and LOD tests are performed on the CPU (the host). I have explored performing LOD calculations on the GPU but this is a substantially complex task, and one which I feel the current generation of GL APIs are ill-suited to achieve.
Streaming terrain height data from the GPU to host address space is completely feasible and seamless if done correctly. Unfortunately the low-level GL APIs to achieve the required asynchronous 'feedback' are not exposed by the Unity Engine - native plugins are required, none of which currently exist. Joerg keeps hounding me to write one though
Anyway, you don't need the full patch height data to determine the appropriate patch-AABB: all you need is the maximum and minimum vertex heights for that patch. This can be approximated through a low-frequency/octave procedural height 'sampling' on the CPU (create a low resolution version of the patch host-side), or measured by analysis of the entire patch's height map. In the latter case, this can be achieved quickly on the GPU by using a parallel scan operation, and then sending back the two results (min and max). Asynchronous transfer is still required in this case, but the memory bandwidth requirement is drastically reduced compared to sending the entire patch's heightmap and determining min/max on the host.
Back to your original request, I will provide a verbal summary for how I build the transformation matrix - it's not a simple copy-paste because the calculation takes place in stages throughout multiple parts of the generation system.
Each of my patches has a center point (not actually aligned with a vertex due to using and even-by-even # of vertices per side, i.e. 128x128), and that point is defined by an azimuth and elevation. Each face of the quadsphere defines an azimuthal and elevational rotation axis. For example, the Z+ (normal) face (in a right-handed coordinate system) has an azimuthal axis of +Y, and an elevational axis of +X. All patches belonging to that +Z face reference these axes of rotation.
As an example, the LOD-0 (one patch) for this face has an az/el value of 0 and 0. The LOD-1 patches have the following az/el values:
corner AZ EL
top-right +45 -45
top-left -45 -45
bottom-left -45 +45
bottom-right +45 +45
These rotation values can be applied to a unit vector of the face's normal vector - i.e. of (0,0,1) for the +Z face. The rotations can be applied in either order, resulting in a unit vector pointing from the planet's origin to the center of the patch once the patch has been 'sphericalized' (all vertices normalized).
This center vector is the first key element of the transformation matrix from world-to-patch space. I usually refer to this as the patch's 'up' vector, or the patch's 'normal' vector (as opposed to an individual vertex's normal vector).
The patch space's coordinate system is thus defined:
Patch 'tangent' vector: take a unit vector having the same direction as the face's elevation rotation axis, and rotate it around the face's azimutal rotation axis by the patch's azimuth value.
Patch 'bitangent' vector: take a unit vector having the same direction as the face's azimuthal rotation axis, and rotate it around the face's elevational rotation axis by the patch's elevation value.
This yields an orthonormalized 3d basis. You can verify this by ensuring Tangent cross Bi-tangent equals Normal.
A standard change of basis matrix may be constructed with this knowledge of the patch's basis defined using worldspace vectors (technically, these are "planetspace" vectors, which could be further transformed in a multi-planetary scenario).
Of note, when constructing the patch-aligned bounding box, I mathmatically assume the patch has zero curvature. This causes deviation of the BB at the lowest LODs, but I've found that it doesn't cause a problem. At higher LODs, the deviation is imperceptable, since the patch curvature is so minute. Thus, construction of the patch-BB is pretty straightforward, as each of the box's axis are aligned with the patch basis.
I hope this has helped you understand how I construct the patch AABBs and how to construct a transformation matrix from planet-space to patch-space.