@CAD97 I was about to disagree strongly, and then I re-read the code. 
So, what happens here is that you have a shared reference to a raw pointer to some location, and then that location gets mutated? Yes, that is definitely okay. None of Rust's guarantees look "through" raw pointers.
The goal is to define a model like Stacked Borrows so that mutability is not something "extra", but instead when you look at the program state you already have there the necessary pieces to track mutability violations (aliasing violations, really, because it's also about uniqueness).
More concretely to your point, I do not see how anything you are doing here is FFI specific. I do not understand what you mean to say by putting "Foreign mutability" next to &mut and &UnsafeCell, but you seem to mean raw pointers, so maybe if anything let's call this "Raw mutability". FFI is not special.
Raw pointers are really in a different class from references, and Rust just makes no assumptions about them, period. So there's not much to say in terms of what you can and cannot do as long as all involved pointers are raw.
I had a hard time figuring out where you are going with your post, so if you have some concrete questions it would help if you could formulate them explicitly. 
You start to conflate several issues here. You started by asking about whether some code is legal (it is). Now you are going into API design. That's also interesting, but it is an entirely independent discussion.
The current best practices for "opaque pointers" are documented in the nomicon. Until extern type lands, that's what we recommend you to use.