A few thoughts...columnstore indexes are all about performance. They are great in a warehouse context (or even OLTP context - see link below) where we need to aggregate a ton of rows. I'm thinking about measures in fact tables. I'd encourage you to not toss these indexes. Instead, give them some more research.
Next, in 2016, everything you are looking for is supported. Here is a real simple example that works
create table dbo.dim (id int not null primary key)
create table dbo.fact (id int not null, dimid int, measure int)
create clustered columnstore index idx_col on dbo.fact
alter table dbo.fact add constraint pk_fact primary key (id)
alter table dbo.fact add constraint fk_fact_dim foreign key (dimid) references dbo.dim (id)
Finally, despite what some would recommend for performance reasons, I always include foreign key constraints in my warehouse tables. No matter how good integration code is, I always want an extra layer of protection to ensure integrity. That said however, you don't need foreign key constraints to have a fact-dimension relationship.
Hope this helps a little and encourages you to keep exploring columnstore indexes 🙂