You can - but there are a few things that you may want to bear in mind.
Firstly, these attributes are actually facts. For the most part, anything relating to a date is a fact as it is time-sensitive. Therefore, wherever possible, I like to push these down into a fact table. This could be as simple as
Fact.AccountHistory for example, but it really depends on how you will be analysing the data. Sometimes you may even want to push them down into your main fact table such as
Fact.Sales or something similar.
Secondly, it makes maintenance of your data warehouse troublesome. All of those foreign keys cause additional overhead during your ETL process, even if you disable them when doing the load, they have to be rechecked once they are enabled again.
Finally, if you do wish to link the dimensional attributes to a date dimension, then I find it is better to create separate date dimension tables for each one of your attributes. I know initially this sounds counter-intuitive but when you look at the range of queries that it opens up it makes a lot of sense.
If you link all date attributes to the same dimension table, then it makes it difficult when you need to apply multiple independent filters. What if I only want to see customers who were born in December but I also want to aggregate the sales by the month they were purchased? Using a single date dimension means that this query is a lot harder than it needs to be. If I have separate date dimensions it is pretty easy to do.
This technique is called role-playing dimensions. Here is the description from the Kimble website:
A single physical dimension can be referenced multiple times in a fact table, with each reference linking to a logically distinct role for the dimension. For instance, a fact table can have several dates, each of which is represented by a foreign key to the date dimension. It is essential that each foreign key refers to a separate view of the date dimension so that the references are independent. These separate dimension views (with unique attribute column names) are called roles.
If you have a lot of date dimensions it can cause your model/warehouse to bloat so a technique that is used commonly is to have multiple views of the date dimension exposed out for each of the attributes that reference it. If I'm not adding too many references to the date dimension, I have no problem having a second physical copy of the table such as
Dimension.GraduationDate which contains only the properties that I know I am going to aggregate/filter by.
By cherry picking what attributes you are interested in you can reduce the overall storage requirements of your warehouse - and most modern database vendors also provide some type of compression that can be applied as well, so this can drastically reduce the overhead of creating multiple date dimensions should you need to.
Ultimately, when building your warehouse, you should know in advance the questions that you are providing answers to. These questions, and the answers required will drive your overall design. Try out multiple approaches and decide which will fit your needs, you may even decide to implement a hybrid approach whereby some dimensions reference the main date table and others reference role-playing dimensions.