This article confirms that the CoS classifier is not supported on the VT interface and additionally specifies why classification cannot be configured as per the implementation logic.

At times, customers want to deploy some CoS components, such as the classifier, on the VT interface for a L3VPN or VPLS scenario. When they try to apply a classifier to the VT interface, there is no classifier option; as shown below:

# set class-of-service interfaces vt-0/0/0 ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
   output-forwarding-class-map Output forwarding class map name
   scheduler-map Output scheduler map

When checking the output of the CoS classifier from the VT interface, they notice that a default INET BA (ipprec-compatibility) is present:

> show class-of-service interface vt-0/0/0
Physical interface: vt-0/0/0, Index: 140
Queues supported: 8, Queues in use: 8                     ?
   Scheduler map: <default-chassis> , Index: 4             ?
   Chassis scheduler map: <default-chassis> , Index: 4

   Logical interface: vt-0/0/0.6, Index: 520
      Object         Name                     Type     Index
      Classifier     ipprec-compatibility     ip       13

Also, technical documentation (CoS configuration guide and Service Interface configuration guide) explicitly specifies that the tunnel interfaces, such as  VT-, PD-/PE- interfaces, do not support CoS configurations.

This is by design.

After a classifier is applied to the core or CE facing interface and the traffic passes the VT interface and gets looped back, the forwarding-class IDs that are mapped to the packets with the queues information will remain unchanged.
 
As per the implementation logic, classification is skipped for tunnel interfaces (such as VT-); unlike in the LSI scenario.