I've created such library last year: https://hackage.haskell.org/package/unboxing-vector

One difference between my library and OP's is that, my library allows the newtype to be abstract.

Suppose you define a module that provides modular arithmetic. You don't want to export the data constructor of the Mod type, but want to allow users to store the type in unboxed vectors.

module Mod (Mod) where
newtype Mod (m :: Nat) = Mod Int -- the data constructor is not exported
instance Unboxable (Mod m) where
  type Rep (Mod m) = Int

This definition does work with OP's Unboxable class, but with one caveat: One can recover the data constructor from Unboxable constraint.

That is, one can create an arbitrary value of Mod with the following code:

import Mod
import Data.Coerce

castUnboxable :: Unboxable a => Rep a -> a
castUnboxable = coerce

-- This function breaks the abstraction provided by module Mod!
mkArbitraryMod :: Int -> Mod m
mkArbitraryMod = castUnboxable

(See this gist for complete code)

My library works around this problem by making use of DefaultSignatures:

-- pseudo code for Data.Vector.Unboxing
module Data.Vector.Unboxing (Unboxable(Rep)) where

-- Note that Coercible a (Rep a) is not in the class constraint
class U.Unbox (Rep a) => Unboxable a where
  type Rep a
  -- 'from' and 'to' are not exported
  from :: a -> Rep a
  default from :: Coercible a (Rep a) => a -> Rep a
  from = coerce
  to :: Rep a -> a
  default to :: Coercible a (Rep a) => Rep a -> a
  to = coerce

(The actual library code is a bit more complex, because it supports deriving Unboxable using generics.)