There's probably an error occurring somewhere in the process, because that would cause exactly what you're seeing.
Here's why:
When you define a view, the views or tables referenced by that view must already exist:
mysql> CREATE VIEW broken_view AS SELECT some_column FROM nonexistent_table;
ERROR 1146 (42S02): Table 'test.nonexistent_table' doesn't exist
For this reason, mysqldump generates a dump file that includes statements defining all of the views as equivalent(ish) tables, then goes back one by one and drops the tables and creates the views. This avoids the problem that would occur if any view referenced another view, or referenced a table that hadn't been restored yet (tables are restored in alphabetical order).
The error could be while generating the dump file -- if any of your existing views are invalid -- for example, they reference tables or columns that don't exist, or reference DEFINER users that don't exist or don't have proper permissions, or if you don't have sufficient privileges -- their definitions can't be extracted, because SHOW CREATE VIEW only works on valid views.
If, by way of illustration, you create a view against a table, then drop the table, you'll find that you can no longer SHOW CREATE VIEW against that view.
If your views reference tables in a different schema that aren't on the destination server, you'd have a similar problem, because their definitions won't be accepted.
Being someone with a strong distaste for almost all graphical tools, I can't stand Workbench, but I believe it uses mysqldump under the hood, so this is likely to be the nature of the problem.
The export file should be human-readable. If, at the end of the file, there are view definitions, then a problem is occurring when you're restoring the file. If not, then you've got a problem preventing the export from finishing, and Workbench may not be showing you the error... but an incomplete export (or import) would be exactly the explanation for views being defined as tables on the destination server.
