The more complex answer is that it depends on what you want to verify and how long can your cycle be. Here is where you start understanding that it will be smarter to use a combination of tests in order to work more efficiently.
Personally I use as little manual GUI tests as possible and try to put as much weight into my API and Functional Automation Suites, this makes the system automatic (and thus it can run at 12:00am and send me an automatic report by mail!). Only if I am satisfied with the results of the automatic procedures will I run a manual smoke test consisting mostly of a CRUD test of all the items in the system.
You can do whatever yo uwant in a Build Verification test as long as it's an accepted practice within your company. Personally, when I think of build verification I think of the build integrity. Does the installer contain all the necessary components to run the application? Does the installer install properly? Does the application launch? Not much past that.
Since build tests should be run against each build, it's important to keep your testing short. If you can test the interface quickly and think it will provide you with something positive, then go for it.
Of course if you have automated GUI test programs like QTP you can add that into your verification test and have it send you a report. Or write a framework around it to collate reports from various automated scripts like we do, we also wanted the late and night automation test with a report so we added what we wanted. Like Joel says though, it all depends on what your company wants.
As stated by the others, you can add as much as you like and as also stated it depends on your organisation. The only other thing I would consider here is the purpose of the test. If your test is about verification of the build and you include GUI tests and the GUI tests fail, does it mean you fail the build?
I'd argue that:
a. This isn't an accurate reflection of the intent of the tests (assumed only by the title of the suite of course)
b. Failure of the GUI tests could detract (in terms of analysis time)from this primary concern.
c. If you've got the resource to identify points of failure as GUI, Build and whatever else you include, fine. If not, would you really want to reject the build for something not 'Build' related?
My five cents (two cents are no longer legal tender in Australia).